Mẫu dữ liệu xử lý trả hàng và hoàn tiền
Mẫu dữ liệu xử lý trả hàng và hoàn tiền
- 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
Các thuộc tính của quy trình xử lý hàng trả lại và hoàn tiền
| Tên | Mô tả | ||
|---|---|---|---|
| Mã yêu cầu trả hàng ReturnCaseId | Mã định danh duy nhất cho một yêu cầu trả hàng của khách, liên kết mọi hoạt động liên quan từ lúc bắt đầu đến khi đóng yêu cầu. | ||
| Mô tả Mã yêu cầu trả hàng là mã định danh chính, dùng để nhóm tất cả sự kiện và hoạt động thuộc cùng một lần trả hàng. Mỗi yêu cầu trả hàng của khách được gán một mã duy nhất để theo dõi toàn bộ quy trình từ đầu đến cuối. Trong process mining, thuộc tính này là nền tảng để tái dựng luồng quy trình. Thuộc tính giúp phân tích thời lượng xử lý từng yêu cầu, các biến thể quy trình và điểm nghẽn bằng cách kết nối những sự kiện riêng lẻ như 'Khởi tạo yêu cầu trả hàng', 'Nhận hàng tại kho' và 'Hoàn tất hoàn tiền' thành một dòng thời gian liền mạch cho từng lần trả hàng. Vì sao điều này quan trọng Đây là khóa thiết yếu để theo dõi một lần trả hàng từ đầu đến cuối, phục vụ mọi phân tích ở cấp yêu cầu, bao gồm thời gian xử lý và việc tìm ra các biến thể quy trình. Lấy dữ liệu ở đâu Thông thường, đây là số chứng từ bán hàng (VBELN) trong bảng phần đầu đơn trả hàng VBAK, nơi loại chứng từ (VBTYP) cho biết đây là đơn trả hàng. Ví dụ 600001896000019060000191 | |||
| Tên hoạt động ActivityName | Tên của một hoạt động nghiệp vụ hoặc sự kiện cụ thể xảy 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 mốc cụ thể trong vòng đời trả hàng. Hoạt động thể hiện công việc đang được thực hiện, chẳng hạn như 'Phê duyệt đơn trả hàng' hoặc 'Hoàn tất kiểm tra hàng trả lại'. Các hoạt động này được xác định từ thay đổi trạng thái, việc tạo chứng từ hoặc hành động cụ thể của người dùng được ghi lại trong SAP S/4HANA. 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 các luồng xử lý phổ biến và hiếm gặp, đồng thời tìm ra những hoạt động thường xuyên lặp lại, dấu hiệu của việc phải làm lại hoặc quy trình kém hiệu quả. Vì sao điều này quan trọng Các hoạt động tạo nên cấu trúc chính của sơ đồ quy trình, giúp trực quan hóa và phân tích luồng quy trình, điểm nghẽn và các biến thể. Lấy dữ liệu ở đâu Tên hoạt động thường được xác định từ nhiều nguồn dữ liệu, chẳng hạn như thay đổi trạng thái chứng từ trong các bảng VBUK/VBUP, sự kiện tạo chứng từ trong các bảng phần đầu như VBAK (chứng từ bán hàng) và BKPF (chứng từ kế toán), cùng trạng thái luân chuyển hàng hóa trong MSEG. Ví dụ Khởi tạo yêu cầu trả hàngNhận hàng tại khoTạo chứng từ ghi cóHoàn tất hoàn tiền | |||
| Thời điểm sự kiện EventTime | Dấu thời gian chính xác cho biết thời điểm một hoạt động cụ thể diễn ra. | ||
| Mô tả Thời điểm sự kiện ghi lại ngày giờ một sự kiện nghiệp vụ được lưu trong hệ thống. Dấu thời gian này rất quan trọng để sắp xếp hoạt động theo trình tự thời gian và thực hiện mọi phân tích dựa trên thời gian. Trong process mining, thuộc tính này được dùng để tính thời gian giữa các hoạt động, xác định thời lượng của từng bước và phân tích hiệu suất quy trình theo thời gian. Đây là cơ sở để tìm ra điểm nghẽn, theo dõi mức độ đáp ứng SLA và hiểu diễn biến theo thời gian của quy trình trả hàng. Vì sao điều này quan trọng Dấu thời gian này rất cần thiết để sắp xếp sự kiện, tính mọi khoảng thời gian và thời gian xử lý, đồng thời xác định các khâu chậm trễ. Lấy dữ liệu ở đâu Thông thường, dữ liệu được lấy từ các trường ngày và giờ gắn với việc tạo chứng từ hoặc thay đổi trạng thái, chẳng hạn ERDAT (Ngày tạo) và ERZET (Giờ tạo) trong các bảng như VBAK, LIKP và BKPF, hoặc ngày hạch toán (BUDAT) trong chứng từ kế toán. Ví dụ 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdateTimestamp | Dấu thời gian cho biết dữ liệu của sự kiện này được làm mới hoặc trích xuất lần gần nhất khi nào. | ||
| Mô tả Thuộc tính này ghi lại ngày giờ của lần trích xuất hoặc cập nhật dữ liệu gần nhất. Đây là siêu dữ liệu cho biết bộ dữ liệu được phân tích có mới hay không. Thông tin này giúp bạn biết phân tích process mining có dựa trên dữ liệu mới nhất hay không. Người dùng có thể xem dữ liệu được cập nhật đến thời điểm nào, đặc biệt hữu ích khi theo dõi hoạt động và dùng bảng điều khiển để giám sát các yêu cầu đang xử lý. Vì sao điều này quan trọng Cho biết dữ liệu mới đến đâu, yếu tố quan trọng để đảm bảo các phân tích và bảng điều khiển dựa trên thông tin cập nhật. Lấy dữ liệu ở đâu Thông thường, công cụ ETL hoặc đường ống dữ liệu tạo và gắn dấu thời gian này vào bộ dữ liệu khi trích xuất. Ví dụ 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Mã hệ thống nguồn SourceSystemId | Mã định danh của hệ thống nguồn nơi dữ liệu được trích xuất. | ||
| Mô tả Thuộc tính này cho biết hệ thống ghi nhận dữ liệu ban đầu của sự kiện. Với quy trình này, đó thường là mã phiên bản SAP S/4HANA. Trong môi trường có nhiều hệ thống, trường này rất quan trọng để theo dõi nguồn gốc dữ liệu, xử lý sự cố và đảm bảo tính toàn vẹn của dữ liệu. Trường này giúp phân biệt dữ liệu khi hàng trả lại được xử lý trên nhiều phiên bản ERP hoặc tích hợp với các hệ thống bên ngoài như hệ thống quản lý kho. Vì sao điều này quan trọng Cung cấp thông tin quan trọng về nguồn gốc và luồng dữ liệu, nhất là trong môi trường có nhiều hệ thống, giúp đảm bảo khả năng truy xuất và độ tin cậy của dữ liệu. Lấy dữ liệu ở đâu Giá trị này thường không thay đổi và được cấu hình khi trích xuất dữ liệu. Bạn có thể lấy giá trị từ thông tin quản trị của hệ thống SAP, chẳng hạn như System ID (SID). Ví dụ S4H_PROD_100S4Q_DEV_200 | |||
| Lý do trả hàng ReturnReason | Lý do khách hàng đưa ra khi trả hàng. | ||
| Mô tả Thuộc tính này ghi lại lý do khách hàng nêu khi trả hàng, chẳng hạn như 'Sản phẩm bị lỗi', 'Sai kích cỡ' hoặc 'Không còn nhu cầu'. Thông thường, khách hàng chọn lý do từ danh sách mã có sẵn khi bắt đầu yêu cầu trả hàng. Phân tích lý do trả hàng rất quan trọng để xác định vấn đề về chất lượng sản phẩm, cải thiện mô tả sản phẩm hoặc điều chỉnh quy trình bán hàng. Dữ liệu này cho thấy trực tiếp nguyên nhân khiến khách hàng không hài lòng và giúp doanh nghiệp ưu tiên các lĩnh vực cần cải thiện để giảm tỷ lệ trả hàng. Vì sao điều này quan trọng Cho biết lý do hàng bị trả lại, giúp phân tích nguyên nhân gốc rễ để xử lý vấn đề về chất lượng sản phẩm, lỗi giao hàng hoặc chênh lệch giữa kỳ vọng của khách hàng và sản phẩm. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong bảng mặt hàng của đơn bán hàng trả lại (VBAP), tại trường ABGRU (Lý do từ chối chứng từ bán hàng). Ví dụ 001 - Chất lượng kém002 - Hư hỏng trong quá trình vận chuyển005 - Giao sai mặt hàng | |||
| Mã khách hàng CustomerId | Mã định danh duy nhất của khách hàng gửi yêu cầu trả hàng. | ||
| Mô tả Thuộc tính này xác định khách hàng yêu cầu trả hàng. Thuộc tính liên kết một lần xử lý với một đối tượng cụ thể trong dữ liệu chính khách hàng. Phân tích hàng trả lại theo khách hàng giúp xác định các mẫu hành vi, chẳng hạn như khách hàng có tỷ lệ trả hàng cao bất thường, có thể là dấu hiệu gian lận hoặc không hài lòng. Thuộc tính này cũng cho phép phân nhóm quy trình trả hàng theo loại khách hàng, giá trị hoặc lịch sử giao dịch để điều chỉnh mức độ phục vụ phù hợp. Vì sao điều này quan trọng Liên kết hàng trả lại với từng khách hàng, giúp phân tích hành vi, phân nhóm khách hàng và xác định những người thường xuyên trả hàng. Lấy dữ liệu ở đâu Thông tin này có trong trường mã khách hàng (KUNNR) ở bảng phần đầu đơn trả hàng (VBAK). Ví dụ CUST-001234CUST-005678CUST-009012 | |||
| Mã sản phẩm ProductId | Mã định danh duy nhất của mặt hàng được trả lại. | ||
| Mô tả Thuộc tính này xác định vật tư hoặc sản phẩm được trả lại. Thuộc tính liên kết quy trình trả hàng với một mặt hàng cụ thể trong danh mục sản phẩm. Phân tích hàng trả lại theo sản phẩm là cách quan trọng để xác định mặt hàng có tỷ lệ trả cao, có thể do lỗi chất lượng, mô tả sản phẩm chưa rõ hoặc vấn đề trong sản xuất. Dữ liệu này giúp doanh nghiệp đưa ra quyết định phù hợp về thiết kế sản phẩm, quản lý nhà cung cấp và chiến lược hàng tồn kho. Vì sao điều này quan trọng Liên kết quy trình trả hàng với từng sản phẩm, giúp phân tích tỷ lệ trả hàng theo mặt hàng và xác định vấn đề về chất lượng hoặc mô tả sản phẩm. Lấy dữ liệu ở đâu Thông tin này có trong trường mã vật tư (MATNR) ở bảng mặt hàng của đơn trả hàng (VBAP) hoặc bảng mặt hàng của chứng từ giao hàng trả lại (LIPS). Ví dụ FG-10023HW-45981SW-LICENSE-PREM | |||
| Số tiền hoàn RefundAmount | Giá trị tiền cuối cùng được 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 sau khi hoàn tất quy trình trả hàng. Giá trị này được ghi trong các chứng từ tài chính như chứng từ ghi có. Đây là chỉ số tài chính quan trọng, được dùng trong nhiều phân tích. Chỉ số này cần thiết cho bảng điều khiển 'Phân tích chênh lệch số tiền hoàn' để so sánh với số tiền khách yêu cầu. Bạn cũng có thể phân nhóm hàng trả lại theo giá trị để xác định liệu các trường hợp giá trị cao có quy trình khác hoặc mất nhiều thời gian xử lý hơn hay không. Vì sao điều này quan trọng Theo dõi tác động tài chính của hàng trả lại, rất cần thiết để phân tích độ chính xác của khoản hoàn, xác định các trường hợp giá trị cao và hiểu tổng chi phí. Lấy dữ liệu ở đâu Dữ liệu được lấy từ trường giá trị thuần (NETWR) của chứng từ ghi có, trong các bảng như VBRK (Phần đầu chứng từ thanh toán) hoặc BSEG (Mục chứng từ kế toán). Ví dụ 125.50999.0049.99 | |||
| Tên người dùng UserName | Mã người dùng của nhân viên thực hiện hoạt động. | ||
| Mô tả Thuộc tính này xác định người dùng hoặc tác nhân hệ thống cụ thể chịu trách nhiệm hoàn thành một tác vụ, chẳng hạn phê duyệt trả hàng hoặc tạo chứng từ ghi có. Trong SAP, thông tin này thường được lưu trong các trường ghi lại người tạo hoặc người thay đổi chứng từ. Phân tích theo người dùng giúp xác định cá nhân hoặc nhóm có hiệu suất cao, nhu cầu đào tạo và cách phân bổ khối lượng công việc. Thông tin này cũng rất cần thiết khi điều tra sai lệch, vì liên kết hành động trong quy trình với từng người dùng, hỗ trợ công tác tuân thủ và kiểm toán. Vì sao điều này quan trọng Liên kết hoạt động trong quy trình với từng người dùng, giúp phân tích hiệu suất nhóm, khối lượng công việc và mức độ tuân thủ. Lấy dữ liệu ở đâu Thông tin này thường có trong các bảng phần đầu chứng từ, chẳng hạn ERNAM (Người tạo) trong VBAK (Đơn bán hàng), LIKP (Chứng từ giao hàng) và BKPF (Chứng từ kế toán). Có thể bổ sung thông tin người dùng từ bảng dữ liệu chính người dùng USR21. Ví dụ CBROWNASMITHWF_BATCH | |||
| Thời điểm kết thúc sự kiện EventEndTime | Dấu thời gian đánh dấu lúc một hoạt động hoàn tất, dùng để tính thời lượng của hoạt động đó. | ||
| Mô tả Trong khi StartTime (EventTime) đánh dấu lúc một hoạt động bắt đầu, EventEndTime cho biết lúc hoạt động kết thúc. Với nhiều sự kiện do hệ thống tạo, thời điểm bắt đầu và kết thúc giống nhau vì sự kiện diễn ra tức thời. Tuy nhiên, thuộc tính này rất quan trọng với các hoạt động có thời lượng đo được, chẳng hạn như 'Kiểm tra hàng trả lại'. Thuộc tính này giúp tính trực tiếp thời gian xử lý của từng hoạt động. Đây là cơ sở quan trọng để phân tích hiệu suất và xác định bước cụ thể nào đang tốn nhiều thời gian nhất, thay vì chỉ xem xét khoảng thời gian giữa các bước. Vì sao điều này quan trọng Giúp tính chính xác thời lượng của từng hoạt động, từ đó xác định các khâu kém hiệu quả trong từng bước cụ thể của quy trình. Lấy dữ liệu ở đâu Giá trị này thường được suy ra. Một số hoạt động có thể có trường riêng, nhưng phổ biến hơn là dùng StartTime của hoạt động tiếp theo trong cùng yêu cầu. Ví dụ 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Có làm lại IsRework | Cờ cho biết một hoạt động trong trường hợp có lặp lại hoạt động trước đó hay không. | ||
| Mô tả Thuộc tính dạng đúng/sai được tính toán này xác định các lần làm lại, tức là một hoạt động được thực hiện nhiều lần trong cùng một trường hợp. Ví dụ: mặt hàng phải được kiểm tra lại, hoặc chứng từ ghi có được tạo, hủy rồi tạo lại. Thuộc tính này rất cần thiết cho bảng điều khiển “Phân tích công việc làm lại trong quy trình xử lý hoàn tiền” và KPI “Tỷ lệ làm lại khi hoàn tiền”. Thuộc tính giúp đo lường sự kém hiệu quả của quy trình bằng cách làm nổi bật các hoạt động dễ phát sinh lỗi hoặc cần thực hiện nhiều lần, qua đó chỉ ra những khâu cần kiểm soát hoặc đào tạo tốt hơn. Vì sao điều này quan trọng Làm nổi bật sự kém hiệu quả và lỗi trong quy trình bằng cách đánh dấu công việc bị lặp lại, giúp cải tiến đúng trọng tâm để giảm lãng phí và chậm trễ. Lấy dữ liệu ở đâu Cờ này thường do công cụ process mining tính toán hoặc được tính trước trong bước chuyển đổi dữ liệu. Cờ kiểm tra xem cùng tên hoạt động đã xuất hiện trước đó trong cùng trường hợp hay chưa. Ví dụ truefalse | |||
| Có tự động hóa IsAutomated | Cờ cho biết hoạt động do hệ thống hay con người thực hiện. | ||
| Mô tả Thuộc tính dạng đúng/sai này phân biệt hoạt động do hệ thống tự động thực hiện, chẳng hạn qua workflow hoặc tác vụ chạy nền, với hoạt động do người dùng thực hiện thủ công. Thuộc tính này rất cần thiết để tính KPI “Tỷ lệ phê duyệt hoàn tiền tự động” và xác định cơ hội tăng mức độ tự động hóa. Khi lọc các tác vụ thủ công, doanh nghiệp có thể tập trung cải tiến quy trình vào những khâu mà tự động hóa mang lại lợi ích lớn nhất về tốc độ, chi phí và độ chính xác. Vì sao điều này quan trọng Phân biệt tác vụ thủ công và tự động, giúp xác định cơ hội tự động hóa và đo lường tác động của chuyển đổi số. Lấy dữ liệu ở đâu Thông tin này thường được xác định dựa trên Tên người dùng. Ví dụ, nếu người dùng là “WF_BATCH” hoặc một mã hệ thống khác, hoạt động sẽ được đánh dấu là tự động. Ví dụ truefalse | |||
| Đáp ứng SLA hoàn tiền RefundSlaAdherence | Cờ cho biết khoản hoàn tiền 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 kiểm tra xem hoạt động “Đã xử lý hoàn tiền” có diễn ra vào hoặc trước “Ngày mục tiêu hoàn tất SLA hoàn tiền” hay không. Thuộc tính cho biết rõ từng trường hợp có đáp ứng SLA hay không. Đây là chỉ số cốt lõi của bảng điều khiển “Theo dõi việc đáp ứng SLA hoàn tiền” và KPI “Tỷ lệ đáp ứng SLA hoàn tiền”. Chỉ số giúp đo lường hiệu suất so với cam kết với khách hàng, đồng thời xác định các trường hợp chưa đạt kỳ vọng để phân tích nguyên nhân gốc rễ gây chậm trễ. Vì sao điều này quan trọng Đo trực tiếp hiệu suất so với cam kết với khách hàng, là chỉ báo quan trọng về chất lượng dịch vụ và mức độ hài lòng của khách hàng. Lấy dữ liệu ở đâu Được tính bằng cách so sánh EventTime của hoạt động “Đã xử lý hoàn tiền” với “RefundSlaTargetDate” của từng trường hợp. Ví dụ truefalse | |||
| Kết quả kiểm tra mặt hàng ItemInspectionOutcome | Kết quả kiểm tra thực tế mặt hàng được trả lại. | ||
| Mô tả Thuộc tính này ghi lại kết quả kiểm tra sau khi hàng được nhận tại kho. Các kết quả thường gặp gồm “Chấp nhận, có thể bán lại”, “Từ chối, hàng bị hư hỏng” hoặc “Chấp nhận, có thể tân trang”. Dữ liệu này cung cấp thông tin quan trọng cho các bước tiếp theo của quy trình. Kết quả kiểm tra quyết định khách hàng được hoàn tiền toàn bộ, một phần hay không được hoàn tiền. Phân tích kết quả giúp xác định lý do từ chối và cung cấp thông tin để cải thiện bao bì sản phẩm hoặc lựa chọn đối tác vận chuyển nếu hàng thường xuyên bị hư hỏng trong quá trình giao nhận. Vì sao điều này quan trọng Giải thích cơ sở quyết định duyệt hoặc từ chối hoàn tiền, đồng thời cung cấp dữ liệu hữu ích về tình trạng mặt hàng và lý do điều chỉnh khoản hoàn tiền. Lấy dữ liệu ở đâu Thông tin này có thể được ghi trong lô kiểm tra của phân hệ quản lý chất lượng (QM), hoặc dưới dạng trạng thái hay mã lý do trên dòng hàng của chứng từ giao hàng trả lại (LIPS). Thông tin cũng có thể nằm trong một trường tùy chỉnh. Ví dụ Chấp nhận, có thể bán lạiChấp nhận, cần tân trangTừ chối, khách hàng làm hư hỏngTừ chối, trả nhầm mặt hàng | |||
| Mã chính sách trả hàng ReturnPolicyId | Mã định danh của chính sách trả hàng áp dụng cho trường hợp trả hàng cụ thể này. | ||
| Mô tả Thuộc tính này cho biết chính sách trả hàng hoặc bộ quy tắc nào áp dụng cho giao dịch. Chính sách có thể khác nhau tùy theo loại sản phẩm, nhóm khách hàng hoặc thời gian kể từ khi mua hàng. Dữ liệu này rất cần thiết cho bảng điều khiển “Tổng quan về tuân thủ chính sách trả hàng”. Khi gắn từng trường hợp với một chính sách, hệ thống có thể tự động kiểm tra việc tuân thủ các quy tắc, chẳng hạn như thời hạn trả hàng hoặc yêu cầu về tình trạng sản phẩm, đồng thời đánh dấu các trường hợp sai lệch để phân tích. Vì sao điều này quan trọng Cho phép tự động kiểm tra việc tuân thủ các quy tắc kinh doanh, giúp đảm bảo hàng trả lại được xử lý nhất quán và đúng chính sách. Lấy dữ liệu ở đâu Trường này thường không có sẵn trong SAP và có thể cần được xác định dựa trên logic kinh doanh, sử dụng dữ liệu như loại sản phẩm, khách hàng và ngày bán. Nếu được triển khai, trường này có thể được lưu trong một trường tùy chỉnh. Ví dụ STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Ngày mục tiêu hoàn tất SLA hoàn tiền RefundSlaTargetDate | Ngày mục tiêu cần xử lý xong khoản hoàn tiền cho trường hợp trả hàng. | ||
| Mô tả Thuộc tính này xác định thời hạn trong Thỏa thuận mức dịch vụ (SLA) để xử lý khoản hoàn tiền. Ngày này thường được tính theo quy tắc kinh doanh, chẳng hạn một số ngày nhất định sau khi yêu cầu trả hàng được duyệt hoặc hàng được nhận. Trường này là cơ sở cho bảng điều khiển “Theo dõi việc đáp ứng SLA hoàn tiền” và KPI liên quan. Trường này giúp chủ động theo dõi các trường hợp có nguy cơ trễ SLA và phân tích nguyên nhân gốc rễ gây chậm trễ, từ đó cải thiện mức độ hài lòng của khách hàng. Vì sao điều này quan trọng Làm cơ sở đo lường việc đáp ứng SLA, giúp theo dõi hiệu suất, ưu tiên các trường hợp tồn đọng lâu và cải thiện mức độ hài lòng của khách hàng. Lấy dữ liệu ở đâu Trường này hầu như luôn được tính toán từ dữ liệu khác. Logic tính dựa trên một ngày mốc, chẳng hạn ngày tạo yêu cầu trả hàng, cộng với khoảng thời gian theo quy tắc kinh doanh. Khoảng thời gian này có thể phụ thuộc vào loại khách hàng hoặc lý do trả hàng. Ví dụ 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Nhân sự xử lý ProcessingAgent | Nhân sự hoặc nhóm tài nguyên cụ thể chịu trách nhiệm xử lý một hoạt động thủ công. | ||
| Mô tả Thuộc tính này xác định người hoặc nhóm đã thực hiện một tác vụ. Trong môi trường dịch vụ dùng chung, thông tin này có thể cụ thể hơn “Tên người dùng” vì cho biết vai trò hoặc nhóm phụ trách. Dữ liệu này hữu ích cho bảng điều khiển “Hiệu quả phê duyệt hoàn tiền”, giúp phân tích hiệu suất của từng nhân sự hoặc nhóm. Qua đó, bạn có thể hiểu cách phân bổ khối lượng công việc, xác định nhu cầu đào tạo và ghi nhận những cá nhân hoặc nhóm có cách làm hiệu quả để chia sẻ. Vì sao điều này quan trọng Cho phép phân tích hiệu suất theo từng nhân sự hoặc nhóm, hỗ trợ quản lý khối lượng công việc, xác định nhu cầu đào tạo và nâng cao hiệu quả. Lấy dữ liệu ở đâu Thông tin này có thể có trong các chức năng Business Partner của SAP nếu đã phân công nhân sự xử lý. Ngoài ra, có thể xác định thông tin từ phòng ban hoặc vai trò của người dùng trong cơ cấu tổ chức nhân sự. Ví dụ Nhóm hỗ trợ cấp 1Nhóm kiểm tra khoPhòng tài chính - AP | |||
| Số chứng từ ghi có CreditMemoNumber | Mã định danh duy nhất của chứng từ ghi có, dùng để cho phép hoàn tiền. | ||
| Mô tả Chứng từ ghi có là chứng từ thanh toán chính thức, dùng để ghi có vào tài khoản khách hàng cho các mặt hàng đã trả lại. Thuộc tính này là mã duy nhất của chứng từ tài chính đó. Theo dõi số chứng từ ghi có rất cần thiết để phân tích khâu quyết toán tài chính trong quy trình trả hàng. Đây là một mốc quan trọng, thường kích hoạt khoản hoàn tiền thực tế, đồng thời cần thiết cho việc đối soát tài chính và kiểm toán. Vì sao điều này quan trọng Đại diện cho giao dịch tài chính chính thức của khoản hoàn tiền, rất quan trọng để theo dõi các bước cuối của quy trình và phục vụ kiểm toán tài chính. Lấy dữ liệu ở đâu Đây là số chứng từ thanh toán (VBELN) trong bảng phần đầu chứng từ thanh toán (VBRK), nơi loại chứng từ cho biết đây là chứng từ ghi có. Ví dụ 900003459000034690000347 | |||
| Số chứng từ giao hàng trả lại ReturnDeliveryNumber | Mã định danh duy nhất của chứng từ giao hàng trả lại. | ||
| Mô tả Khi khách hàng gửi trả hàng hóa, SAP tạo chứng từ giao hàng trả lại để quản lý khâu hậu cần nhập hàng. Thuộc tính này là mã duy nhất của chứng từ đó. Mã này rất quan trọng để theo dõi quá trình di chuyển thực tế của hàng trả lại. Mã liên kết khía cạnh tài chính và hậu cần của việc trả hàng, giúp phân tích chi tiết các giai đoạn nhận hàng và kiểm tra. Vì sao điều này quan trọng Tạo liên kết quan trọng giữa đơn trả hàng và việc nhận hàng thực tế, cần thiết để phân tích khâu hậu cần và thời gian xử lý tại kho. Lấy dữ liệu ở đâu Đây là số chứng từ giao hàng (VBELN) trong bảng phần đầu chứng từ giao hàng (LIKP), nơi loại chứng từ cho biết đây là chứng từ giao hàng trả lại. Ví dụ 840000128400001384000014 | |||
| Số tiền hoàn được yêu cầu RequestedRefundAmount | Số tiền hoàn ban đầu được yêu cầu hoặc dự kiến khi bắt đầu quy trình. | ||
| Mô tả Thuộc tính này ghi lại giá trị hàng hóa theo yêu cầu trả hàng ban đầu. Đây là mức cơ sở để so sánh với số tiền hoàn cuối cùng. Trường này cần thiết riêng cho bảng điều khiển 'Phân tích chênh lệch số tiền hoàn'. So sánh số tiền được yêu cầu với số tiền thực tế được hoàn giúp xác định các vấn đề như hoàn tiền một phần do hàng hư hỏng, phí nhập lại kho hoặc các khoản điều chỉnh khác, qua đó đảm bảo tính chính xác và minh bạch về tài chính. Vì sao điều này quan trọng Dùng làm mốc để đo độ chính xác của khoản hoàn tiền, giúp xác định và phân tích chênh lệch giữa số tiền dự kiến và số tiền thực tế. Lấy dữ liệu ở đâu Thường lấy từ giá trị thuần của các mặt hàng trong đơn hàng bán trả lại ban đầu. Đây là giá trị thuần (NETWR) của các dòng hàng tương ứng trong bảng VBAP. Ví dụ 125.501050.0049.99 | |||
| Tổ chức bán hàng SalesOrganization | Đơn vị tổ chức chịu trách nhiệm về giao dịch bán hàng ban đầu và việc trả hàng. | ||
| Mô tả Tổ chức bán hàng là một thành phần quan trọng trong cơ cấu tổ chức SAP, đại diện cho đơn vị chịu trách nhiệm bán và phân phối sản phẩm, dịch vụ. Đơn vị này được gán cho giao dịch trả hàng. Thuộc tính này giúp lọc và so sánh quy trình trả hàng giữa các đơn vị kinh doanh, khu vực hoặc bộ phận. Qua đó, bạn có thể xác định tổ chức bán hàng nào có tỷ lệ trả hàng cao hơn hoặc xử lý hàng trả lại kém hiệu quả hơn, làm cơ sở phân tích hiệu suất giữa các đơn vị. Vì sao điều này quan trọng Giúp so sánh hiệu suất và tỷ lệ trả hàng giữa các đơn vị kinh doanh, khu vực hoặc kênh bán hàng. Lấy dữ liệu ở đâu Thông tin này có trong trường tổ chức bán hàng (VKORG) ở bảng phần đầu đơn trả hàng (VBAK). Ví dụ 10002100US01 | |||
| Trạng thái đơn hàng trả lại ReturnOrderStatus | Trạng thái tổng thể hiện tại của trường hợp trả hàng. | ||
| Mô tả Thuộc tính này cho biết trạng thái tổng quan của trường hợp trả hàng tại một thời điểm, chẳng hạn “Đang mở”, “Đang xử lý” hoặc “Đã đóng”. Trạng thái này thường được tổng hợp từ cột mốc chính gần nhất đã hoàn tất. Thông tin này rất cần thiết cho bảng điều khiển “Trạng thái hiện tại của các trường hợp trả hàng”, giúp theo dõi khối lượng công việc và phân bổ các trường hợp. Nhờ đó, người quản lý biết có bao nhiêu trường hợp đang ở mỗi giai đoạn, từ đó phân bổ tài nguyên và quản lý công việc hiệu quả hơn. Vì sao điều này quan trọng Cho biết mỗi trường hợp đang ở đâu trong quy trình, rất cần thiết cho các bảng điều khiển vận hành theo dõi khối lượng công việc và trạng thái hiện tại. Lấy dữ liệu ở đâu Được xác định từ các trường trạng thái trên những chứng từ liên quan. Ví dụ: trạng thái tiêu đề (GBSTK) hoặc trạng thái mặt hàng (LFSTK) trong đơn hàng bán liên quan (VBUK/VBUP) hoặc chứng từ giao hàng. Ví dụ Chờ nhận hàngChờ kiểm traChờ hoàn tiềnĐã đóng | |||
| Tuân thủ chính sách trả hàng ReturnPolicyAdherence | Cờ cho biết trường hợp trả hàng có tuân thủ chính sách trả hàng đã quy định hay không. | ||
| Mô tả Thuộc tính dạng đúng/sai được tính toán này cho biết trường hợp trả hàng có đáp ứng các tiêu chí trong chính sách áp dụng hay không. Logic có thể kiểm tra, chẳng hạn, yêu cầu trả hàng có được gửi trong thời hạn cho phép hay lý do trả hàng có hợp lệ với sản phẩm hay không. Thuộc tính này hỗ trợ trực tiếp cho bảng điều khiển “Tổng quan về tuân thủ chính sách trả hàng”. Thuộc tính giúp tính tỷ lệ tuân thủ và đi sâu xuống các trường hợp không tuân thủ để tìm hiểu nguyên nhân sai lệch, qua đó giúp thực thi chính sách hiệu quả hơn. Vì sao điều này quan trọng Đo lường mức độ tuân thủ quy tắc kinh doanh, giúp xác định và giảm các trường hợp vi phạm chính sách có thể ảnh hưởng đến lợi nhuận hoặc gây ngoại lệ trong quy trình. Lấy dữ liệu ở đâu Được tính theo quy tắc kinh doanh. Ví dụ: (Ngày bắt đầu trả hàng - Ngày mua ban đầu) <= [Số ngày được phép trả hàng]. Cần có Ngày mua ban đầu và các quy tắc chính sách để tính. Ví dụ truefalse | |||
Các hoạt động trong quy trình xử lý hàng trả lại và hoàn tiền
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Đóng yêu cầu trả hàng | Đây là hoạt động cuối cùng, cho biết quy trình trả hàng đã hoàn tất và không còn bước nào cần thực hiện cho yêu cầu này. Thông thường, sự kiện được suy ra khi chứng từ đơn trả hàng đạt trạng thái cuối cùng là đã đóng trong hệ thống. | ||
| Vì sao điều này quan trọng Sự kiện này xác định điểm kết thúc vòng đời quy trình, giúp tính tổng thời gian xử lý từ đầu đến cuối. Sự kiện cũng xác nhận yêu cầu đã được giải quyết hoàn toàn. Lấy dữ liệu ở đâu Sự kiện được suy ra khi trạng thái tổng thể của đơn trả hàng trong bảng VBAK hoặc các mặt hàng trong VBAP chuyển sang 'Hoàn tất' hoặc 'Đã đóng'. Trạng thái này được xác định theo cấu hình quản lý trạng thái của hệ thống. Thu thập Sự kiện được suy ra khi trạng thái chứng từ đơn trả hàng chuyển thành 'Hoàn tất'. Loại sự kiện inferred | |||
| Hoàn tất hoàn tiền | Hoạt động này đánh dấu bước cuối của quy trình hoàn tiền, khi khoản ghi có được tất toán, nghĩa là tiền đã được gửi cho khách hàng. Sự kiện được suy ra từ việc tạo chứng từ tất toán trong phân hệ tài chính để thanh toán khoản ghi có còn mở trên tài khoản khách hàng. | ||
| Vì sao điều này quan trọng Đây là thời điểm khách hàng thực sự nhận được tiền. Thời gian từ lúc bắt đầu trả hàng đến bước này ảnh hưởng lớn đến sự hài lòng của khách hàng và là chỉ số quan trọng để đo mức độ đáp ứng SLA. Lấy dữ liệu ở đâu Sự kiện được suy ra từ thông tin chứng từ tất toán trong bảng mục hàng kế toán tài chính BSEG. Ngày tất toán (BSEG-AUGDT) trên mục hàng khách hàng liên quan đến chứng từ ghi có cho biết thời điểm hoàn tiền được xử lý. Thu thập Sự kiện được suy ra khi trường ngày tất toán được điền cho chứng từ kế toán liên quan đến chứng từ ghi có. Loại sự kiện inferred | |||
| Hoàn tất kiểm tra hàng trả lại | Hoạt động này thể hiện việc hoàn tất đánh giá chất lượng và tình trạng của hàng trả lại. Trong Advanced Returns Management, đây thường là bước được ghi nhận rõ ràng, lưu kết quả kiểm tra và xác định hướng xử lý tiếp theo, chẳng hạn hoàn tiền hoặc loại bỏ hàng. | ||
| Vì sao điều này quan trọng Thời lượng và kết quả kiểm tra ảnh hưởng trực tiếp đến thời gian xử lý hoàn tiền và việc quản lý hàng tồn kho. Theo dõi hoạt động này rất quan trọng để phân tích hiệu quả kiểm tra và việc phải làm lại. Lấy dữ liệu ở đâu Trong SAP Advanced Returns Management (ARM), đây có thể là sự kiện được ghi nhận rõ ràng từ giao dịch kiểm tra. Sự kiện cũng có thể được suy ra từ thay đổi trạng thái của mặt hàng trong đơn trả hàng, cho biết kết quả kiểm tra. Thu thập Sự kiện được ghi nhận từ nhật ký giao dịch hoặc thay đổi trạng thái liên quan đến các hoạt động xử lý hậu cần tiếp theo trong ARM. Loại sự kiện explicit | |||
| Khởi tạo yêu cầu trả hàng | Đây là điểm bắt đầu của quy trình trả hàng, khi đơn trả hàng được tạo chính thức trong hệ thống. Sự kiện này được ghi nhận rõ ràng khi một chứng từ bán hàng mới thuộc loại đơn trả hàng được lưu trong SAP S/4HANA. | ||
| Vì sao điều này quan trọng Hoạt động này đánh dấu thời điểm chính thức bắt đầu vòng đời của yêu cầu trả hàng. Phân tích thời gian từ sự kiện này đến khi đóng yêu cầu rất quan trọng để đo tổng thời gian xử lý và đánh giá trải nghiệm khách hàng. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ ràng khi tạo chứng từ bán hàng trong bảng VBAK, với loại chứng từ (VBAK-VBTYP) cho biết đây là đơn trả hàng. Thời điểm tạo được lưu trong VBAK-ERDAT. Thu thập Sự kiện được ghi nhận khi lưu đơn bán hàng trả lại mới, chẳng hạn qua giao dịch VA01. Loại sự kiện explicit | |||
| Nhận hàng tại kho | Sự kiện này đánh dấu thời điểm hàng trả lại được nhận thực tế tại kho hoặc trung tâm xử lý. Sự kiện được ghi nhận rõ ràng khi thực hiện Post Goods Receipt (PGR) cho chứng từ giao hàng trả lại và tạo chứng từ vật tư. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng, bắt đầu tính thời gian kiểm tra và quyết định hướng xử lý. Các chậm trễ trước mốc này thường do khách hàng, còn chậm trễ sau đó thuộc nội bộ doanh nghiệp. Lấy dữ liệu ở đâu Sự kiện được ghi nhận từ các bảng chứng từ vật tư MSEG và MKPF, với loại giao dịch nhập hàng tương ứng với hàng trả lại. Ngày hạch toán (MKPF-BUDAT) cho biết thời điểm xảy ra sự kiện. Thu thập Sự kiện tương ứng với việc hạch toán nhập hàng cho chứng từ giao hàng trả lại. Loại sự kiện explicit | |||
| Tạo chứng từ ghi có | Đây là bước tạo chứng từ thanh toán chính thức để ghi có vào tài khoản khách hàng cho mặt hàng trả lại. Sự kiện được ghi nhận rõ ràng khi tạo chứng từ ghi có từ yêu cầu ghi có. | ||
| Vì sao điều này quan trọng Việc tạo chứng từ ghi có là một mốc tài chính quan trọng. Bước này xác nhận số tiền cần hoàn và cho phép bắt đầu quy trình thanh toán. Lấy dữ liệu ở đâu Sự kiện được ghi nhận khi tạo chứng từ thanh toán trong bảng VBRK, với loại chứng từ cho biết đây là chứng từ ghi có. Chứng từ này được liên kết với yêu cầu ghi có trong bảng VBFA. Thu thập Sự kiện được ghi nhận khi lưu chứng từ thanh toán ghi có mới, chẳng hạn qua giao dịch VF01. Loại sự kiện explicit | |||
| Tạo yêu cầu ghi có | Sau khi kiểm tra đạt yêu cầu, hoạt động này đánh dấu việc tạo yêu cầu ghi có cho khách hàng. Sự kiện được ghi nhận khi tạo chứng từ bán hàng mới thuộc loại yêu cầu ghi có, có tham chiếu đến đơn trả hàng ban đầu. | ||
| Vì sao điều này quan trọng Đây là bước khởi đầu cho phần quyết toán tài chính trong quy trình trả hàng. Phân tích thời gian từ lúc kiểm tra đến bước này cho thấy mức độ hiệu quả khi chuyển giao công việc từ bộ phận hậu cần sang tài chính. Lấy dữ liệu ở đâu Sự kiện được ghi nhận khi tạo chứng từ bán hàng trong bảng VBAK với loại chứng từ là yêu cầu ghi có. Mối liên kết với đơn trả hàng được lưu trong bảng luồng chứng từ VBFA. Thu thập Sự kiện được ghi nhận khi lưu chứng từ yêu cầu ghi có mới. Loại sự kiện explicit | |||
| Phê duyệt đơn trả hàng | Hoạt động này thể hiện đơn trả hàng đã được phê duyệt hoặc giải phóng chính thức để chuyển sang giai đoạn tiếp theo. Thông thường, sự kiện được suy ra từ thay đổi trạng thái ở phần đầu chứng từ bán hàng hoặc ở từng mặt hàng, cho biết các lệnh chặn đã được gỡ bỏ. | ||
| Vì sao điều này quan trọng Các bước phê duyệt có thể gây chậm trễ đáng kể. Theo dõi hoạt động này giúp xác định điểm nghẽn ở giai đoạn cấp phép ban đầu của quy trình trả hàng. Lấy dữ liệu ở đâu Sự kiện được suy ra từ các bảng quản lý trạng thái hoặc các trường trạng thái trong bảng VBAK hay VBAP. Thay đổi trạng thái giải phóng hoặc gỡ chặn giao hàng (VBAP-LIFSP) có thể cho biết đơn đã được phê duyệt. Thu thập Sự kiện được suy ra từ thay đổi ở trường trạng thái phần đầu chứng từ hoặc mặt hàng của đơn trả hàng, cho biết đơn đã được giải phóng hoặc phê duyệt. Loại sự kiện inferred | |||
| Tạo chứng từ giao hàng trả lại | Hoạt động này đánh dấu việc tạo chứng từ giao hàng nhập, dùng để quản lý quá trình nhận hàng trả lại. Hệ thống ghi nhận rõ ràng sự kiện tạo chứng từ giao hàng có tham chiếu đến đơn trả hàng. | ||
| Vì sao điều này quan trọng Đây là một mốc quan trọng trong khâu hậu cần. Thời gian từ lúc phê duyệt trả hàng đến khi tạo chứng từ giao hàng cho thấy mức độ hiệu quả khi chuyển thông tin trả hàng đến kho hoặc bộ phận tiếp nhận. Lấy dữ liệu ở đâu Sự kiện được ghi nhận khi tạo phần đầu chứng từ giao hàng trong bảng LIKP, liên kết với đơn trả hàng trước đó qua bảng luồng chứng từ VBFA. Thu thập Sự kiện được ghi nhận khi lưu chứng từ giao hàng trả lại mới, chẳng hạn qua giao dịch VL01N. Loại sự kiện explicit | |||
| Tạo chứng từ kế toán | Sự kiện này xảy ra khi chứng từ ghi có được hạch toán thành công vào phân hệ kế toán tài chính. Hệ thống tạo các bút toán tương ứng trong sổ cái, chính thức ghi nhận khoản ghi có về mặt kế toán. | ||
| Vì sao điều này quan trọng Hoạt động này xác nhận khoản ghi có đã được đưa vào hệ thống tài chính. Thời gian từ lúc tạo chứng từ ghi có đến khi hạch toán kế toán có thể cho thấy vấn đề trong giao tiếp giữa hệ thống thanh toán và tài chính. Lấy dữ liệu ở đâu Sự kiện được ghi nhận khi tạo phần đầu chứng từ trong bảng kế toán BKPF, có liên kết với chứng từ ghi có trong VBRK (VBRK-BELNR). Thu thập Sự kiện được ghi nhận khi chứng từ thanh toán được hạch toán thành công vào Kế toán tài chính. Loại sự kiện explicit | |||
| Tạo đơn đổi hàng | Hoạt động này thể hiện một hướng xử lý khác: thay vì hoàn tiền, doanh nghiệp tạo đơn bán hàng mới để gửi sản phẩm thay thế cho khách hàng. Sự kiện được ghi nhận khi tạo đơn bán hàng mới có tham chiếu đến đơn trả hàng ban đầu. | ||
| Vì sao điều này quan trọng Hoạt động này giúp phân biệt hàng trả lại để hoàn tiền với hàng trả lại để đổi, vì hai trường hợp có các bước xử lý và kết quả khác nhau cho khách hàng. Đây là thông tin quan trọng để phân tích các biến thể của quy trình. Lấy dữ liệu ở đâu Sự kiện được ghi nhận khi tạo chứng từ bán hàng mới trong VBAK, có liên kết với đơn trả hàng trong bảng luồng chứng từ (VBFA). Thu thập Sự kiện được ghi nhận khi lưu chứng từ đơn bán hàng mới được xác định là đơn hàng thay thế. Loại sự kiện explicit | |||
| Từ chối hàng trả lại | Sự kiện này cho biết hàng trả lại không đáp ứng điều kiện trong chính sách trả hàng và yêu cầu hoàn tiền hoặc ghi có đã bị từ chối. Thông thường, sự kiện được ghi nhận khi áp dụng một trạng thái hoặc mã lý do cụ thể cho mặt hàng trong đơn trả hàng sau khi kiểm tra. | ||
| Vì sao điều này quan trọng Theo dõi các trường hợp bị từ chối giúp phân tích mức độ tuân thủ chính sách trả hàng và xác định những lý do từ chối phổ biến. Đây là một nhánh ngoại lệ quan trọng trong quy trình. Lấy dữ liệu ở đâu Sự kiện được suy ra khi có lý do từ chối (VBAP-ABGRU) trên mặt hàng trong đơn trả hàng hoặc khi một trạng thái cụ thể được gán trong quá trình kiểm tra bằng Advanced Returns Management. Thu thập Sự kiện được suy ra khi có lý do từ chối hoặc trạng thái 'bị từ chối' cụ thể trên mặt hàng trong chứng từ trả hàng. Loại sự kiện inferred | |||
Hướng dẫn trích xuất dữ liệu
Các bước
- Kiểm tra điều kiện tiên quyết: Đảm bảo tài khoản người dùng chạy trích xuất có đủ quyền trong SAP S/4HANA để truy cập các CDS View cần thiết. Các view chính gồm I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry và I_ClearedItem.
- Mở công cụ truy vấn: Đăng nhập vào ứng dụng SQL hoặc công cụ tích hợp dữ liệu bạn muốn dùng, đã kết nối với cơ sở dữ liệu SAP S/4HANA. Công cụ có thể là sản phẩm của SAP như SAP Analytics Cloud hoặc một nền tảng ETL bên thứ ba.
- Đặt tham số truy vấn: Trước khi chạy, bạn cần chỉnh sửa truy vấn SQL được cung cấp. Tìm các giá trị giữ chỗ và thay bằng tham số đúng với môi trường của bạn. Bao gồm
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]và các bộ lọc loại chứng từ hoặc mã công ty khác. - Chạy truy vấn trích xuất: Sao chép toàn bộ truy vấn SQL và chạy trong công cụ. Truy vấn thu thập mọi hoạt động đã chỉ định vào một tập dữ liệu duy nhất bằng cách hợp nhất kết quả từ nhiều câu lệnh select.
- Tìm hiểu logic truy vấn: Mỗi khối
SELECTtrong cấu trúcUNION ALLtrích xuất một hoạt động cụ thể. Khối này kết hợp nhiều CDS view để lấy các thuộc tính cần thiết, gán một chuỗi cố định choActivityNamevà chọn dấu thời gian phù hợp choEventTime. - Kiểm tra dữ liệu thô: Sau khi truy vấn chạy xong, kiểm tra nhanh kết quả. Xem số dòng có hợp lý không và các cột chính như
ReturnCaseId,ActivityNamevàEventTimecó dữ liệu như mong đợi không. - Chuyển đổi dữ liệu: Truy vấn được thiết kế để tạo nhật ký sự kiện dạng phẳng. Thông thường không cần thay đổi nhiều về cấu trúc. Tuy nhiên, bạn có thể cần điều chỉnh định dạng dấu thời gian hoặc kiểu dữ liệu theo yêu cầu của hệ thống đích.
- Xuất nhật ký sự kiện: Xuất kết quả truy vấn thành tệp CSV. Đảm bảo tệp dùng mã hóa UTF-8 để tránh lỗi ký tự, nhất là với tên người dùng hoặc mô tả sản phẩm.
- Tải lên công cụ process mining: Tệp CSV đã sẵn sàng để tải lên nền tảng process mining như ProcessMind. Ánh xạ các cột trong tệp với trường tương ứng trong công cụ, chẳng hạn
ReturnCaseIdsang ID trường hợp,ActivityNamesang Hoạt động vàEventTimesang Dấu thời gian.
Cấu hình
- Điều kiện tiên quyết: Người thực hiện cần có quyền xem các đối tượng liên quan đến chứng từ bán hàng (VBAK), giao hàng (LIKP), lập hóa đơn (VBRK) và kế toán (BSEG, BKPF). Cần có quyền truy cập các CDS View bên dưới.
- Bộ lọc phạm vi dữ liệu: Cần lọc truy vấn theo loại chứng từ cụ thể để tách riêng quy trình hàng trả lại. Thiết lập các giá trị giữ chỗ cho loại đơn hàng trả lại (ví dụ: 'RE'), loại yêu cầu phiếu ghi có (ví dụ: 'G2') và loại đơn hàng đổi hàng (ví dụ: 'SO'). Bạn cũng nên lọc theo
CompanyCodehoặcSalesOrganizationđể giới hạn phạm vi dữ liệu. - Lọc theo khoảng ngày: Luôn áp dụng bộ lọc ngày để kiểm soát hiệu suất và dung lượng dữ liệu. Hãy bắt đầu với dữ liệu trong 3 đến 6 tháng gần nhất. Truy vấn dùng ngày tạo đơn hàng trả lại ban đầu (
I_SalesDocument.CreationDate) làm điều kiện lọc chính. - Lưu ý về hiệu suất: Truy vấn này kết hợp nhiều CDS View lớn nên có thể tiêu tốn nhiều tài nguyên trên hệ thống S/4HANA nguồn. Hãy lên lịch trích xuất ngoài giờ cao điểm để giảm ảnh hưởng. Với tập dữ liệu rất lớn, hãy cân nhắc chiến lược tải dữ liệu tăng dần.
Truy vấn mẫu sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Các bước
- Xác nhận bạn có quyền đọc trực tiếp lược đồ SAP HANA chứa dữ liệu bán hàng, giao hàng, lập hóa đơn, chứng từ vật tư, kiểm tra, trạng thái và kế toán liên quan. Lược đồ, view và tên trường cụ thể tùy theo cách triển khai SAP S/4HANA. Vì vậy, hãy thay từng giá trị giữ chỗ trong ngoặc vuông bằng đối tượng và trường được cấu hình trong hệ thống của bạn.
- Xác định phạm vi trích xuất bằng
[Start date],[End date],[Company Code filter]và[Return document type filter]. Ban đầu, hãy trích xuất dữ liệu trong khoảng thời gian luân phiên từ ba đến sáu tháng. Chỉ mở rộng khoảng thời gian sau khi đã xác nhận hiệu suất và tính đầy đủ của dữ liệu. - Xác định tập đơn hàng trả lại từ
[Your sales document header table]và[Your sales document item table]. Giới hạn tập dữ liệu ở các loại chứng từ đơn hàng trả lại được cấu hình trong[Your return order document type configuration]. Giữ lại số đơn hàng trả lại và số dòng hàng làm khóa liên kết chính với các chứng từ tiếp theo. - Dùng
[Your document flow table or view]để xác định luồng chứng từ từ đơn hàng trả lại đến phiếu giao hàng trả lại, yêu cầu phiếu ghi có, đơn hàng đổi hàng và phiếu ghi có. Không giả định luồng chứng từ được lưu trong VBAK hoặc VBAP. Hãy cấu hình các trường liên kết theo mô hình luồng chứng từ của hệ thống. - Trích xuất các sự kiện tạo rõ ràng từ bản ghi đầu trang và dòng hàng của chứng từ liên quan. Lấy các sự kiện phê duyệt, từ chối, kiểm tra, đóng hồ sơ, nhận hàng, kế toán và đối soát từ các nguồn trạng thái, kiểm tra, chứng từ vật tư, kế toán và đối soát đã cấu hình. Mỗi hoạt động phải được xuất thành một dòng sự kiện riêng vì ProcessMind không tự suy ra sự kiện.
- Chuẩn hóa dấu thời gian về cùng một kiểu dấu thời gian cơ sở dữ liệu và múi giờ. Dùng thứ tự ưu tiên dấu thời gian sự kiện đã cấu hình cho từng hoạt động. Nếu chỉ có ngày và giờ riêng, hãy kết hợp chúng theo múi giờ hệ thống được cấu hình trong
[Your system time zone]. - Điền
ReturnCaseIdcho mọi sự kiện. Dùng số đơn hàng trả lại ban đầu hoặc mã hồ sơ trả lại đã cấu hình nếu Advanced Returns Management lưu khóa hồ sơ riêng. Loại trừ các sự kiện không thể liên kết với hồ sơ trả lại hoặc đưa chúng vào tệp ngoại lệ để xử lý. - Điền các cột bắt buộc
ReturnCaseId,ActivityName,EventTime,SourceSystemIdvàLastDataUpdateTimestamp. Điền các cột nên có nếu dữ liệu sẵn có, gồmEventEndTime,UserName,ReturnReason,RefundAmount,ProductIdvàCustomerId. Giữ một dòng cho mỗi lần hoạt động diễn ra, không gộp hoạt động thành một dòng cho mỗi hồ sơ. - Kiểm tra kết quả theo các bước trong
validationSteps. Xác nhận có đủ tên của cả mười hai hoạt động, dấu thời gian trong từng hồ sơ có thứ tự hợp lý và thông tin tham chiếu chứng từ khớp với các bảng nguồn. - Xuất kết quả thành tệp CSV UTF-8 hoặc định dạng bảng khác được ProcessMind hỗ trợ. Giữ nguyên tên cột chính xác, chỉ dùng một dòng tiêu đề, lưu dấu thời gian theo định dạng ISO rõ ràng và tải nhật ký sự kiện lên với
ReturnCaseIdlàm mã hồ sơ,ActivityNamelàm cột hoạt động.
Cấu hình
- Khoảng ngày: Bắt đầu với dữ liệu trong ba đến sáu tháng. Dùng tham số
[Start date]và[End date], đồng thời lấy đủ dữ liệu lịch sử để bao gồm các hồ sơ bắt đầu trước khoảng thời gian đã chọn nhưng hoàn tất trong khoảng đó. - Tập đơn hàng trả lại: Lọc theo loại chứng từ đơn hàng trả lại được cấu hình trong
[Your return order document type configuration]. Không cố định loại chứng từ nếu chưa xác minh loại đó trong hệ thống đích. - Bộ lọc tổ chức: Chỉ áp dụng
[Company Code filter], tổ chức bán hàng, kênh phân phối, ngành hàng, nhà máy hoặc bộ lọc khách hàng khi cần. Xác nhận các bộ lọc không loại bỏ chứng từ tiếp theo giữa các công ty hoặc trong nội bộ tập đoàn. - Đối tượng nguồn: Thay các giá trị giữ chỗ
[Your table name]và[Your view name]bằng bảng SAP S/4HANA hoặc CDS View đã được phê duyệt. Hệ thống có thể có VBAK, VBAP, VBRK và VBRP, nhưng cần xác minh trước khi chạy. - Xử lý dấu thời gian: Cấu hình trường dấu thời gian nguồn và múi giờ cho từng hoạt động. Lưu
EventTimevàEventEndTimenhất quán, tốt nhất theo UTC hoặc múi giờ ProcessMind đã thống nhất. - Diễn giải trạng thái: Cấu hình chính xác các giá trị trạng thái, mã lý do, kết quả kiểm tra và chỉ báo đóng hồ sơ thể hiện việc phê duyệt, từ chối, hoàn tất kiểm tra và đóng hồ sơ trong hệ thống.
- Mã hệ thống nguồn: Thay
[Source system identifier]bằng một giá trị ổn định, chẳng hạn mã hệ thống SAP mà nền tảng trích xuất sử dụng. - Dấu thời gian làm mới: Thay
[Extraction timestamp]bằng thời điểm truy vấn bắt đầu chạy hoặc ảnh chụp dữ liệu nguồn được tạo. Dùng cùng một giá trị cho mọi dòng trong một lần trích xuất, trừ khi cần dấu thời gian làm mới riêng cho từng dòng. - Hiệu suất: Giới hạn tập đơn hàng trả lại ban đầu trước khi kết hợp với các nguồn luồng chứng từ, kế toán, chứng từ vật tư và trạng thái có dung lượng lớn. Dùng trường có chỉ mục hoặc hỗ trợ loại bỏ phân vùng, tránh quét toàn bộ dữ liệu và chỉ lưu kết quả trung gian khi quản trị viên cơ sở dữ liệu phê duyệt.
- Trích xuất tăng dần: Với các lần chạy định kỳ, dùng
[Last successful extraction timestamp]cùng khoảng thời gian chồng lấn được kiểm soát để lấy các cập nhật đến muộn. Loại bản ghi trùng dựa trênReturnCaseId,ActivityName, khóa chứng từ nguồn vàEventTime. - Quyền truy cập và điều kiện tiên quyết: Xin quyền đọc tất cả đối tượng và trường nguồn đã cấu hình, phê duyệt quyền truy cập trực tiếp cơ sở dữ liệu và xác nhận các thành phần SAP cần thiết cùng chức năng Advanced Returns Management đang hoạt động nếu áp dụng.
- Bảo vệ dữ liệu: Chỉ lấy các trường khách hàng và tài chính ở mức tối thiểu cần thiết, tuân thủ các biện pháp bảo vệ quyền riêng tư của tổ chức và bảo mật các tệp đã xuất.
Truy vấn mẫu sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Sẵn sàng bắt đầu?
Mẫu này cung cấp kiến thức nền tảng để bạn trích xuất và phân tích dữ liệu xử lý hàng trả lại và hoàn tiền. Bắt đầu cải tiến quy trình ngay hôm nay.
Cải tiến quy trình xử lý hàng trả lại và hoàn tiền trên SAP S/4HANA ngay hôm nay
Xác định điểm chưa hiệu quả, rút ngắn 30% thời gian xử lý và nâng cao mức độ hài lòng.
Không cần thẻ tín dụng. Bắt đầu cải tiến ngay hôm nay.