Mẫu dữ liệu xử lý thanh toán khoản phải trả
Mẫu dữ liệu xử lý thanh toán khoản phải trả
- Các thuộc tính chính để phân tích nhà cung cấp và thanh toán
- Các mốc quy trình thiết yếu trong chu kỳ thanh toán
- Logic trích xuất chuyên biệt cho hệ thống SAP S/4HANA
Các thuộc tính xử lý thanh toán khoản phải trả
| Tên | Mô tả | ||
|---|---|---|---|
| Hoạt động Activity | Tác vụ hoặc thay đổi trạng thái sự kiện cụ thể được ghi nhận cho hóa đơn. | ||
| Mô tả Thuộc tính này thể hiện các bước riêng biệt trong vòng đời hóa đơn. Thuộc tính ghi nhận các sự kiện như tạo, ghi sổ, chặn, phê duyệt và tất toán thanh toán. Tên hoạt động được lấy từ mã giao dịch, mục nhật ký thay đổi hoặc cập nhật trạng thái workflow trong hệ thống nguồn. Trường này rất quan trọng khi phân tích các biến thể của luồng quy trình. Công cụ process mining dùng trường này để trực quan hóa trình tự các bước, phát hiện vòng lặp làm lại và xác định điểm quy trình lệch khỏi luồng chuẩn. Đây là thành phần cốt lõi của nhật ký sự kiện. Vì sao điều này quan trọng Thuộc tính này xác định các nút trên sơ đồ quy trình, giúp trực quan hóa quy trình làm việc và các điểm nghẽn. Lấy dữ liệu ở đâu Lấy từ mã giao dịch (TCODE) hoặc phần đầu (CDHDR) và mục (CDPOS) của chứng từ thay đổi Ví dụ Hóa đơn đã hạch toánĐã áp dụng lệnh chặn thanh toánChạy thanh toánHóa đơn đã tất toán | |||
| Số hóa đơn InvoiceNumber | Mã nhận diện duy nhất của hóa đơn nhà cung cấp đang được xử lý. | ||
| Mô tả Số hóa đơn là Case ID chính để theo dõi vòng đời của khoản phải trả trong hệ thống SAP S/4HANA. Đây là số chứng từ kế toán được tạo khi ghi sổ hóa đơn vào sổ cái. Theo thuật ngữ SAP tiêu chuẩn, trường này tương ứng với Số chứng từ (BELNR), thuộc một Mã công ty và Năm tài chính cụ thể. Trong phân tích quy trình, thuộc tính này đóng vai trò Case ID. Nó liên kết mọi hoạt động riêng lẻ, từ lúc nhận và tạm giữ hóa đơn, qua các bước chặn và chỉnh sửa để phê duyệt, đến khi thanh toán được tất toán. Nhóm sự kiện theo mã này giúp chuyên viên phân tích dựng lại toàn bộ lịch sử từ đầu đến cuối của từng nghĩa vụ thanh toán. Vì sao điều này quan trọng Đây là Case ID chính thức, giúp dựng lại toàn bộ luồng quy trình thanh toán từ đầu đến cuối. Lấy dữ liệu ở đâu Bảng SAP BKPF (phần đầu chứng từ kế toán), trường BELNR hoặc trường BELNR trong ACDOCA Ví dụ 1900000523510000289119000006015100003002 | |||
| Thời điểm sự kiện EventTime | Dấu thời gian chính xác khi hoạt động diễn ra. | ||
| Mô tả Thời điểm sự kiện ghi lại ngày giờ cụ thể khi một hoạt động được ghi vào cơ sở dữ liệu SAP. Thuộc tính này cung cấp thông tin thời gian để sắp xếp sự kiện theo trình tự trong từng trường hợp. Dấu thời gian thường được tạo bằng cách kết hợp trường Ngày CPU và Giờ CPU từ nhật ký hệ thống hoặc phần đầu chứng từ. Khi phân tích, thuộc tính này rất cần thiết để tính thời gian chu kỳ, thời lượng và thông lượng. Thuộc tính giúp đo khoảng thời gian giữa các bước, chẳng hạn thời gian từ lúc nhận hóa đơn đến khi phê duyệt cuối cùng. Đây là cơ sở để xác định điểm nghẽn và đánh giá KPI như Thời gian phê duyệt hóa đơn trung bình. Vì sao điều này quan trọng Thuộc tính này xác định thứ tự thời gian của các sự kiện và là cơ sở cho mọi phép tính hiệu suất theo thời gian. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường CPUDT (ngày nhập) và CPUTM (giờ nhập), hoặc các trường UDATE và UTIME trong CDHDR Ví dụ 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Hệ thống nguồn SourceSystem | Mã nhận diện phiên bản SAP S/4HANA nơi dữ liệu được tạo ra. | ||
| Mô tả Thuộc tính này xác định hệ thống ERP hoặc máy khách cụ thể nơi trích xuất dữ liệu quy trình. Trong môi trường có nhiều phiên bản SAP hoặc hệ thống cũ chạy song song, trường này giúp duy trì nguồn gốc dữ liệu và so sánh giữa các hệ thống. Khi phân tích, trường này đóng vai trò bộ lọc cấp cao. Trường giúp chuyên viên phân tích tách riêng dữ liệu để so sánh hiệu suất giữa các hệ thống ở từng khu vực hoặc kiểm tra tính nhất quán của dữ liệu trong các dự án chuyển đổi hệ thống. Nhờ đó, các khác biệt của quy trình do cấu hình hệ thống được đặt đúng bối cảnh. Vì sao điều này quan trọng Thuộc tính này phân biệt nguồn dữ liệu trong môi trường nhiều hệ thống, giúp phân nhóm chính xác. Lấy dữ liệu ở đâu Mã hệ thống (SY-SYSID) trong thông tin cài đặt SAP Ví dụ SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian cho biết lần gần nhất bản ghi được trích xuất hoặc làm mới. | ||
| Mô tả Lần cập nhật dữ liệu gần nhất đánh dấu thời điểm dữ liệu được tải thành công vào nền tảng process mining. Thuộc tính này không phản ánh thời điểm sự kiện nghiệp vụ diễn ra, mà cho biết dữ liệu đã được cập nhật đến đâu. Đây là yếu tố quan trọng để người dùng tin cậy vào dữ liệu phân tích trên bảng điều khiển. Khi phân tích, thuộc tính này giúp người dùng biết thông tin đang xem có mới hay không. Thuộc tính đặc biệt quan trọng khi theo dõi các bảng điều khiển gần thời gian thực như Phân tích chặn thanh toán, để đảm bảo quyết định dựa trên trạng thái mới nhất của hệ thống SAP S/4HANA. Vì sao điều này quan trọng Thuộc tính này cho người dùng biết dữ liệu mới đến đâu, điều rất quan trọng với bảng điều khiển vận hành. Lấy dữ liệu ở đâu Được tạo bởi quy trình ETL / trích xuất Ví dụ 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Điều khoản thanh toán PaymentTerms | Mã thể hiện các điều kiện thanh toán và chiết khấu đã thỏa thuận. | ||
| Mô tả Điều khoản thanh toán quy định thời điểm hóa đơn đến hạn và liệu có được chiết khấu tiền mặt khi thanh toán sớm hay không. Mã này, chẳng hạn 'Z001', tương ứng với các quy tắc như 'Thanh toán trong 30 ngày' hoặc 'Chiết khấu 2% nếu thanh toán trong 10 ngày, hạn thanh toán 30 ngày'. Mã được sao chép từ dữ liệu chủ nhà cung cấp sang hóa đơn nhưng có thể được thay đổi thủ công. Thuộc tính này là trọng tâm của các bảng điều khiển Tối ưu hóa chiết khấu thanh toán sớm và Tuân thủ điều khoản thanh toán của nhà cung cấp. Hệ thống dùng thuộc tính này để tính ngày đến hạn cơ sở và xác định khoản thanh toán có được thực hiện trong khoảng thời gian tối ưu để hưởng chiết khấu hay không. Vì sao điều này quan trọng Thuộc tính này quy định thời hạn dự kiến và ưu đãi tài chính, rất quan trọng khi phân tích chiết khấu. Lấy dữ liệu ở đâu Bảng SAP BSEG, trường ZTERM Ví dụ Z001NT300001 | |||
| Không cần can thiệp thủ công IsTouchless | Cờ boolean cho biết hóa đơn có được xử lý mà không cần can thiệp thủ công hay không. | ||
| Mô tả Thuộc tính này được tính bằng cách phân tích luồng sự kiện của một trường hợp. Nếu trường hợp chỉ gồm các hoạt động tự động, chẳng hạn do người dùng 'system' thực hiện hoặc dùng các TCODE chạy nền cụ thể, và không có thay đổi thủ công hay trạng thái chặn, trường hợp đó được đánh dấu là không cần can thiệp thủ công. Đây là chỉ số chính cho KPI Tỷ lệ hóa đơn không cần can thiệp thủ công. Chỉ số này giúp tổ chức theo dõi hiệu quả của các sáng kiến tự động hóa và xác định loại trường hợp nào, chẳng hạn theo Nhà cung cấp hoặc Khu vực, có thể đi qua hệ thống mà không cần người xử lý. Vì sao điều này quan trọng Đây là thước đo chính về mức độ tự động hóa và hiệu quả của quy trình. Lấy dữ liệu ở đâu Được tính dựa trên trình tự hoạt động và loại người dùng Ví dụ truefalse | |||
| Loại chứng từ DocumentType | Phân loại chứng từ kế toán, chẳng hạn hóa đơn nhà cung cấp, khoản thanh toán hoặc giấy báo có. | ||
| Mô tả Loại chứng từ là mã gồm hai ký tự trong SAP, dùng để phân loại giao dịch kế toán. Các loại thường gặp gồm 'KR' cho hóa đơn nhà cung cấp, 'KZ' cho khoản thanh toán nhà cung cấp và 'RE' cho hóa đơn nhận hàng tổng. Loại chứng từ quy định dải số và trạng thái trường của chứng từ. Khi phân tích, thuộc tính này được dùng để lọc phạm vi quy trình. Ví dụ, chuyên viên phân tích có thể loại trừ giấy báo có để chỉ tập trung vào hiệu quả thanh toán đi. Thuộc tính này cũng giúp xác định cơ cấu các loại giao dịch đang được xử lý và hỗ trợ bảng điều khiển Độ phức tạp của biến thể quy trình. Vì sao điều này quan trọng Thuộc tính này phân loại trường hợp, chẳng hạn hóa đơn hay giấy báo có, để lọc dữ liệu phân tích. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường BLART Ví dụ KRREKZKG | |||
| Lý do chặn thanh toán PaymentBlockReason | Mã cho biết lý do hóa đơn bị chặn thanh toán. | ||
| Mô tả Thuộc tính này chứa mã lý do cụ thể khiến hóa đơn không được đưa vào lần chạy thanh toán tự động. Ví dụ: 'A' là chặn thanh toán, 'R' là xác minh hóa đơn hoặc chặn thủ công do người dùng đặt. Khi phân tích, trường này là yếu tố chính của bảng điều khiển Phân tích chặn thanh toán thủ công. Bằng cách tổng hợp tần suất của từng lý do chặn, doanh nghiệp có thể tìm ra vấn đề mang tính hệ thống, chẳng hạn chênh lệch giá thường xuyên hoặc thiếu phiếu nhận hàng, khiến quy trình thanh toán bị đình trệ. Vì sao điều này quan trọng Thuộc tính này xác định nguyên nhân cụ thể khiến quy trình bị dừng, giúp phân tích nguyên nhân gốc rễ có trọng tâm. Lấy dữ liệu ở đâu Bảng SAP BSEG, trường ZLSPR Ví dụ ABR* | |||
| Mã công ty CompanyCode | Đơn vị tổ chức dùng để lập bảng cân đối kế toán và báo cáo lãi lỗ. | ||
| Mô tả Mã công ty đại diện cho một đơn vị kế toán độc lập trong doanh nghiệp. Đây là đơn vị tổ chức trung tâm trong kế toán đối ngoại, dùng để cấu trúc dữ liệu tài chính. Mỗi hóa đơn được gán cho đúng một Mã công ty. Khi phân tích, thuộc tính này giúp phân nhóm KPI theo pháp nhân hoặc khu vực. Các bảng điều khiển dùng thuộc tính này để so sánh hiệu quả của các nhóm công nợ phải trả giữa các công ty con. Ví dụ, thuộc tính này giúp xác định liệu một chi nhánh có tỷ lệ chặn thanh toán thủ công cao hơn mức chuẩn của công ty hay không. Vì sao điều này quan trọng Thuộc tính này phân nhóm quy trình theo pháp nhân, giúp so sánh hiệu suất nội bộ. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường BUKRS Ví dụ US01DE1010002000 | |||
| Mã nhà cung cấp VendorNumber | Mã nhận diện duy nhất của nhà cung cấp liên quan đến hóa đơn. | ||
| Mô tả Mã nhà cung cấp tương ứng với tài khoản chủ nợ cụ thể trong sổ phụ SAP. Mã này liên kết hóa đơn với dữ liệu chủ, bao gồm điều khoản thanh toán, thông tin ngân hàng và thông tin liên hệ. Trong S/4HANA, mã này thường được liên kết với khái niệm Đối tác kinh doanh, nhưng nhiều bảng vẫn dùng tên trường cũ là LIFNR. Khi phân tích, thuộc tính này là nền tảng cho bảng điều khiển Tuân thủ điều khoản thanh toán của nhà cung cấp. Chuyên viên phân tích có thể tổng hợp hiệu suất quy trình theo nhà cung cấp, từ đó xác định những nhà cung cấp thường gây ra tình trạng chặn, chênh lệch giá hoặc chậm trễ. Thông tin này hỗ trợ quyết định tìm nguồn cung ứng chiến lược và quản lý quan hệ với nhà cung cấp. Vì sao điều này quan trọng Thuộc tính này giúp tổng hợp hiệu suất theo nhà cung cấp, rất cần thiết để tìm nguyên nhân gốc rễ của sự chậm trễ. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường LIFNR hoặc bảng ACDOCA, trường LIFNR Ví dụ 100050VEND-US-99200400 | |||
| Ngày đến hạn ròng NetDueDate | Ngày phải thanh toán hóa đơn để tránh bị phạt. | ||
| Mô tả Ngày đến hạn ròng là hạn thanh toán cuối cùng. Ngày này được tính bằng cách cộng số ngày tối đa theo điều khoản thanh toán vào Ngày cơ sở. Một số hệ thống lưu sẵn ngày này, nhưng trong các chế độ xem phân tích, ngày thường được tính toán. Khi phân tích, đây là mốc chính cho công cụ Theo dõi thanh toán trễ và tiền phạt. So sánh Ngày tất toán thực tế với Ngày đến hạn ròng sẽ cho biết chỉ số 'Số ngày thanh toán trễ', giúp đánh giá hiệu quả của nhóm công nợ phải trả và nguy cơ ảnh hưởng đến quan hệ với nhà cung cấp. Vì sao điều này quan trọng Đây là hạn mục tiêu của quy trình. Nếu không đáp ứng, xếp hạng tín dụng có thể bị ảnh hưởng và phát sinh chi phí. Lấy dữ liệu ở đâu Được tính bằng: Ngày cơ sở + số ngày tối đa theo điều khoản thanh toán (ZBD1T/ZBD2T/ZBD3T) Ví dụ 2023-11-302023-12-01 | |||
| Ngày tất toán ClearingDate | Ngày hóa đơn được tất toán bằng khoản thanh toán. | ||
| Mô tả Ngày tất toán ghi lại thời điểm khoản mục còn mở trong sổ công nợ phải trả được cân đối, thường là qua lần chạy thanh toán hoặc bút toán thanh toán thủ công. Đây cũng là thời điểm kết thúc nghĩa vụ phải trả. Khi phân tích, thuộc tính này được dùng để tính thời gian chu kỳ cuối cùng của quy trình. Đây là dấu thời gian của hoạt động 'Thanh toán được tất toán' và được so sánh với Ngày đến hạn ròng để xác định hiệu suất thanh toán đúng hạn. Dữ liệu này được đưa trực tiếp vào bảng điều khiển Hiệu quả tất toán thanh toán. Vì sao điều này quan trọng Thuộc tính này đánh dấu quy trình thanh toán đã hoàn tất và được dùng để xác định khoản thanh toán có đúng hạn hay không. Lấy dữ liệu ở đâu Bảng SAP BSEG hoặc trường AUGDT trong AUGDT Ví dụ 2023-11-012023-11-15 | |||
| Số tiền hóa đơn InvoiceAmount | Tổng số tiền gồm thuế của hóa đơn theo đơn vị tiền tệ trên chứng từ. | ||
| Mô tả Thuộc tính này thể hiện giá trị tài chính của hóa đơn như được ghi trên chứng từ nguồn. Đây là khoản phải trả cho nhà cung cấp. Trong SAP S/4HANA, giá trị này thường được lưu trong trường Số tiền theo đơn vị tiền tệ trên chứng từ. Khi phân tích, số tiền hóa đơn giúp ưu tiên công việc. Các bảng điều khiển như Phân bổ điểm chạm thủ công dùng trường này để cho thấy liệu các hoạt động thủ công tốn nhiều công sức có đang bị dùng cho những hóa đơn giá trị thấp hay không. Nhờ đó, doanh nghiệp có thể tập trung cải tiến vào các giao dịch giá trị cao, nơi lỗi quy trình gây rủi ro tài chính lớn hơn. Vì sao điều này quan trọng Thuộc tính này cho biết giá trị tài chính của từng trường hợp, cần thiết để ưu tiên xử lý các điểm kém hiệu quả trong quy trình có giá trị cao. Lấy dữ liệu ở đâu Bảng SAP BKPF hoặc BSEG, trường WRBTR Ví dụ 1500.00250.5010000.00 | |||
| Tên người dùng UserName | Mã người dùng đã thực hiện hoạt động cụ thể. | ||
| Mô tả Tên người dùng ghi lại mã đăng nhập của người hoặc tác nhân hệ thống chịu trách nhiệm thực hiện một bước trong quy trình. Đây có thể là người dùng nhập dữ liệu thủ công hoặc mã của một tác vụ chạy nền, chẳng hạn 'BATCH_USER', thực hiện công việc tự động. Khi phân tích, thuộc tính này giúp tính Tỷ lệ tự động hóa hoạt động. Bằng cách phân biệt người dùng với tài khoản hệ thống, chuyên viên phân tích có thể đo mức độ tự động hóa của quy trình. Thuộc tính này cũng được dùng trong bảng điều khiển Phân bổ điểm chạm thủ công để đánh giá khối lượng công việc giữa các nhóm. Vì sao điều này quan trọng Thuộc tính này phân biệt công việc thủ công với công việc tự động, giúp tính tỷ lệ tự động hóa. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường USNAM hoặc bảng CDHDR, trường USERNAME Ví dụ BSMITHWF-BATCHRJONES | |||
| Thanh toán trễ IsLatePayment | Cờ boolean cho biết khoản thanh toán có được thực hiện sau ngày đến hạn ròng hay không. | ||
| Mô tả Thuộc tính được tính toán này trả về true nếu Ngày thanh toán bù trừ muộn hơn Ngày đến hạn ròng. Thuộc tính này phân loại hiệu quả quy trình theo hai trạng thái. Khi phân tích, cờ này được dùng để đếm số trường hợp không tuân thủ cho KPI Tần suất phạt thanh toán trễ. Nhờ đó, bạn có thể tạo dashboard bằng cách đếm các giá trị 'True', thay vì phải tính toán ngày tháng phức tạp ngay trên phần trực quan hóa. Vì sao điều này quan trọng Thuộc tính này giúp tính KPI về tỷ lệ thanh toán đúng hạn dễ dàng hơn. Lấy dữ liệu ở đâu Được tính: Ngày thanh toán bù trừ > Ngày đến hạn ròng Ví dụ truefalse | |||
| Chứng từ mua hàng PurchasingDocument | Số đơn đặt hàng liên quan đến hóa đơn. | ||
| Mô tả Thuộc tính này liên kết hóa đơn với quy trình mua sắm trước đó. Thuộc tính chứa số Đơn đặt hàng (PO) dùng để đối chiếu hóa đơn. Một số hóa đơn, chẳng hạn chi phí phát sinh khác, không có mã PO. Trường này rất quan trọng khi phân tích Tỷ lệ đối chiếu ba bên. Chuyên viên phân tích có thể tách hóa đơn có PO và không có PO, vì hai nhóm thường có quy trình phê duyệt rất khác nhau. Trường này cũng hỗ trợ process mining từ đầu đến cuối bằng cách liên kết dữ liệu công nợ phải trả với dữ liệu mua sắm. Vì sao điều này quan trọng Thuộc tính này liên kết công nợ phải trả với hoạt động mua sắm, hỗ trợ phân tích đối chiếu ba bên và mở rộng phạm vi quy trình. Lấy dữ liệu ở đâu Bảng SAP BSEG, trường EBELN Ví dụ 45000012344500009876 | |||
| Đơn vị tiền tệ Currency | Mã đơn vị tiền tệ của số tiền hóa đơn. | ||
| Mô tả Thuộc tính Đơn vị tiền tệ cho biết số tiền hóa đơn được tính bằng loại tiền nào, chẳng hạn USD, EUR hoặc GBP. Thuộc tính này giúp diễn giải chính xác giá trị tài chính và rất cần thiết khi tổng hợp dữ liệu giữa các mã công ty ở nhiều quốc gia. Khi phân tích, trường này đảm bảo KPI tài chính được tính chính xác. Trường thường được dùng để quy đổi giá trị sang một đơn vị tiền tệ báo cáo chung cho các bảng điều khiển toàn cầu. Nếu thiếu thuộc tính này, các chỉ số tổng hợp như Tổng chi tiêu hoặc Giá trị hóa đơn trung bình sẽ không có ý nghĩa trong môi trường đa tiền tệ. Vì sao điều này quan trọng Thuộc tính này cung cấp ngữ cảnh cho các khoản tiền, cần thiết để lập báo cáo toàn cầu chính xác. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường WAERS Ví dụ USDEURGBPJPY | |||
| Năm tài chính FiscalYear | Năm tài chính mà hóa đơn thuộc về. | ||
| Mô tả Năm tài chính là kỳ dùng cho báo cáo tài chính. Cùng với Mã công ty và Số chứng từ, năm này tạo thành khóa chính ghép của chứng từ tài chính trong SAP. Khi phân tích, đây là thông tin kỹ thuật cần có để nhận diện duy nhất từng trường hợp, đồng thời hỗ trợ báo cáo so sánh giữa các năm. Nhờ đó, Case ID 'Số hóa đơn' vẫn là duy nhất trong dữ liệu lịch sử kéo dài nhiều thập kỷ. Vì sao điều này quan trọng Yêu cầu kỹ thuật để nhận diện duy nhất từng trường hợp trong SAP FI. Lấy dữ liệu ở đâu Bảng SAP BKPF, trường GJAHR Ví dụ 20232024 | |||
| Ngày cơ sở BaselineDate | Ngày bắt đầu áp dụng điều khoản thanh toán và tính ngày đến hạn. | ||
| Mô tả Ngày cơ sở là mốc bắt đầu để tính ngày đến hạn ròng và thời hạn chiết khấu tiền mặt. Tùy cấu hình và dữ liệu chủ nhà cung cấp, ngày này thường là ngày hóa đơn hoặc ngày ghi sổ. Khi phân tích, ngày này là dữ liệu cần có để xác định trạng thái 'Trễ hạn'. Ngày cơ sở sai có thể dẫn đến thanh toán quá sớm, ảnh hưởng dòng tiền, hoặc thanh toán trễ, phát sinh tiền phạt. Kiểm tra độ chính xác của ngày này là một phần trong phân tích Tuân thủ điều khoản thanh toán của nhà cung cấp. Vì sao điều này quan trọng Đây là mốc để tính mọi ngày đến hạn. Lấy dữ liệu ở đâu Bảng SAP BSEG, trường ZFBDT Ví dụ 2023-10-012023-10-15 | |||
| Số ngày hưởng chiết khấu tiền mặt 1 CashDiscountDays1 | Số ngày kể từ ngày cơ sở mà bạn có thể hưởng mức chiết khấu tiền mặt đầu tiên. | ||
| Mô tả Thuộc tính này xác định khoảng thời gian áp dụng điều khoản thanh toán có lợi nhất, chẳng hạn '10' trong 'Chiết khấu 2% nếu thanh toán trong 10 ngày, hạn thanh toán 30 ngày'. Giá trị được lấy từ điều khoản lưu trong dòng mục hóa đơn. Khi phân tích, thuộc tính này giúp xác định 'Ngày mục tiêu' cho công cụ Tối ưu hóa chiết khấu thanh toán sớm. Nếu hóa đơn được tất toán trong khoảng thời gian này, khoản chiết khấu sẽ được hưởng. Trường này giúp đo chi phí cơ hội do chu kỳ xử lý kéo dài. Vì sao điều này quan trọng Thuộc tính này xác định khoảng thời gian có thể tận dụng để tiết kiệm chi phí. Lấy dữ liệu ở đâu Bảng SAP BSEG, trường ZBD1T Ví dụ 10140 | |||
| Số tiền chiết khấu bị mất DiscountLostAmount | Giá trị tiền tệ của khoản chiết khấu thanh toán bằng tiền mặt đủ điều kiện nhưng không được hưởng. | ||
| Mô tả Thuộc tính được tính toán này cho biết khoản tiền doanh nghiệp đã bỏ lỡ. Thuộc tính được xác định bằng cách kiểm tra xem khoản thanh toán có được thực hiện sau hạn chiết khấu hay không. Nếu có, hệ thống tính giá trị chiết khấu bị mất dựa trên tỷ lệ chiết khấu áp dụng cho số tiền hóa đơn. Đây là chỉ số tài chính quan trọng cho công cụ Tối ưu hóa chiết khấu thanh toán sớm. Chỉ số quy đổi sự kém hiệu quả thành khoản tổn thất tiền tệ cụ thể, giúp bạn thấy rõ lợi ích kinh doanh của việc cải tiến quy trình. Vì sao điều này quan trọng Chỉ số này đo lường khoản tổn thất tài chính trực tiếp do quy trình chậm trễ. Lấy dữ liệu ở đâu Được tính: Nếu Ngày thanh toán bù trừ > Ngày chiết khấu, thì Số tiền hóa đơn * Tỷ lệ chiết khấu Ví dụ 30.000.00150.00 | |||
| Tỷ lệ chiết khấu tiền mặt 1 CashDiscountPercentage1 | Tỷ lệ chiết khấu được hưởng nếu thanh toán trong thời hạn chiết khấu đầu tiên. | ||
| Mô tả Thuộc tính này thể hiện tỷ lệ ưu đãi tài chính mà nhà cung cấp dành cho khoản thanh toán sớm, chẳng hạn '2' trong 'Chiết khấu 2% nếu thanh toán trong 10 ngày'. Khi phân tích, thuộc tính này được dùng để tính giá trị 'Chiết khấu tiền mặt tiềm năng'. Nhân tỷ lệ này với Số tiền hóa đơn sẽ cho biết tổng số tiền doanh nghiệp bỏ lỡ do quy trình kém hiệu quả. Thông tin này giúp xây dựng cơ sở cho việc tự động hóa. Vì sao điều này quan trọng Thuộc tính này định lượng mức tiết kiệm tiềm năng, cần thiết để tính ROI. Lấy dữ liệu ở đâu Bảng SAP BSEG, trường ZBD1P Ví dụ 2.03.00.0 | |||
Các hoạt động xử lý thanh toán khoản phải trả
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Chạy thanh toán | Đại diện cho lần chạy thanh toán tạo ra các chỉ thị chuyển tiền. Sự kiện này được theo dõi qua cập nhật trạng thái trong bảng REGUH hoặc REGUP. | ||
| Vì sao điều này quan trọng Cam kết thanh toán trong hoạt động, yếu tố then chốt để phân tích hiệu quả gom nhóm thanh toán. Lấy dữ liệu ở đâu Bảng REGUH, thường được đối chiếu với ngày chạy và mã nhận diện. Thu thập Ghi nhận khi trạng thái Payment Run được cập nhật Loại sự kiện explicit | |||
| Đã áp dụng lệnh chặn thanh toán | Cho biết một dòng hóa đơn đã bị chặn thanh toán nên không được đưa vào đợt thanh toán. Trạng thái này được ghi nhận bằng cách theo dõi thay đổi của trường ZLSPR trong bảng BSEG qua chứng từ thay đổi. | ||
| Vì sao điều này quan trọng Lệnh chặn là nguyên nhân chính gây thanh toán trễ và làm quy trình thêm vướng mắc, đồng thời ảnh hưởng trực tiếp đến bảng điều khiển Phân tích chặn thanh toán thủ công. Lấy dữ liệu ở đâu Bảng CDPOS và CDHDR (Chứng từ thay đổi), tìm các cập nhật cho trường BSEG-ZLSPR. Thu thập Ghi nhận khi bản ghi CDPOS thay đổi giá trị ZLSPR Loại sự kiện explicit | |||
| Đã gỡ lệnh chặn thanh toán | Cho biết lệnh chặn thanh toán đã áp dụng trước đó được gỡ bỏ, nhờ đó hóa đơn được giải phóng để thanh toán. Trạng thái này được xác định khi trường ZLSPR trong BSEG chuyển từ một giá trị sang null hoặc để trống. | ||
| Vì sao điều này quan trọng Thường được dùng thay cho trạng thái 'Hóa đơn đã phê duyệt' trong các hệ thống không có nhật ký quy trình làm việc rõ ràng, đồng thời đánh dấu thời điểm kết thúc giai đoạn bị điểm nghẽn. Lấy dữ liệu ở đâu Bảng CDPOS và CDHDR, tìm trường hợp BSEG-ZLSPR chuyển thành trống. Thu thập Ghi nhận khi CDPOS ghi lại việc xóa ZLSPR Loại sự kiện explicit | |||
| Hóa đơn đã hạch toán | Đây là thời điểm ghi nhận chính thức khoản nợ vào sổ cái. Hoạt động này được xác định từ dấu thời gian tạo trong bảng BKPF hoặc ngày nhập trong bảng ACDOCA. | ||
| Vì sao điều này quan trọng Đây là mốc bắt đầu chính của dòng thời gian tài chính, làm cơ sở xác định ngày đến hạn và phân tích thời gian tồn đọng. Lấy dữ liệu ở đâu Bảng BKPF, dùng CPUDT (Ngày nhập) và CPUTM (Giờ nhập). Thu thập Ghi nhận khi tạo bản ghi BKPF Loại sự kiện explicit | |||
| Tạo chứng từ thanh toán | Tạo chứng từ kế toán ghi có ngân hàng và ghi nợ nhà cung cấp. Thông tin này nằm trong BKPF với loại chứng từ thanh toán, chẳng hạn ZP hoặc KZ. | ||
| Vì sao điều này quan trọng Thời điểm thanh toán được ghi nhận về mặt tài chính, dùng để tính số ngày phải trả bình quân (DPO). Lấy dữ liệu ở đâu Bảng BKPF, lọc theo loại chứng từ (BLART) dành riêng cho thanh toán. Thu thập Ghi nhận khi tạo chứng từ thanh toán BKPF Loại sự kiện explicit | |||
| Thanh toán được tất toán | Đánh dấu bước đối chiếu cuối cùng, khi khoản mục còn mở trong tài khoản nhà cung cấp được tất toán bằng khoản thanh toán. Dữ liệu lấy từ trường AUGDT (ngày tất toán) trong bảng BSEG. | ||
| Vì sao điều này quan trọng Trạng thái cuối cùng của quy trình, cho biết quy trình đã hoàn tất và sổ sách đã cân đối. Tỷ lệ tất toán thủ công cao cho thấy việc đối chiếu chưa hiệu quả. Lấy dữ liệu ở đâu Bảng BSEG, trường AUGDT (ngày tất toán). Thu thập Ghi nhận khi trường AUGDT được điền Loại sự kiện explicit | |||
| Đã tạo đề xuất thanh toán | Cho biết hóa đơn đã được đưa vào một đợt lập đề xuất thanh toán (F110), bước đầu tiên của chương trình thanh toán tự động. Trạng thái này được ghi nhận từ bảng REGUH, nơi lưu dữ liệu thanh toán. | ||
| Vì sao điều này quan trọng Cho biết hóa đơn đã được chọn để thanh toán và vượt qua các bước kiểm tra hợp lệ trong chương trình thanh toán. Lấy dữ liệu ở đâu Thời điểm tạo bảng REGUH (khóa LAUFD và LAUFI). Thu thập Ghi nhận khi tạo bản ghi REGUH Loại sự kiện explicit | |||
| Đã thay đổi điều khoản thanh toán | Ghi nhận thay đổi điều khoản thanh toán của hóa đơn chưa tất toán, làm thay đổi ngày đến hạn hoặc điều kiện nhận chiết khấu. Thay đổi này được theo dõi qua nhật ký cập nhật trường ZTERM trong bảng BSEG. | ||
| Vì sao điều này quan trọng Thay đổi thường xuyên có thể cho thấy lỗi dữ liệu chủ hoặc điều chỉnh thủ công, ảnh hưởng đến dự báo dòng tiền và việc tuân thủ điều khoản thanh toán với nhà cung cấp. Lấy dữ liệu ở đâu Bảng CDPOS và CDHDR, tìm các cập nhật cho trường BSEG-ZTERM. Thu thập Ghi nhận khi bản ghi CDPOS thay đổi giá trị ZTERM Loại sự kiện explicit | |||
| Hóa đơn bị đảo | Cho biết chứng từ hóa đơn đã bị đảo hoặc hủy. Xác định bằng cách kiểm tra trường STBLG (chứng từ đảo) trong bảng BKPF. | ||
| Vì sao điều này quan trọng Cho thấy công việc phải làm lại và quy trình gặp lỗi, giúp nhận diện lãng phí và nguy cơ trùng lặp công việc. Lấy dữ liệu ở đâu Bảng BKPF, trường STBLG không để trống. Thu thập Ghi nhận khi trường STBLG được điền Loại sự kiện explicit | |||
| Hóa đơn đến hạn | Dấu thời gian được tính để thể hiện thời điểm hóa đơn đến ngày đến hạn thanh toán ròng. Giá trị này được xác định bằng cách cộng số ngày theo điều khoản thanh toán vào ngày cơ sở trong bảng BSEG. | ||
| Vì sao điều này quan trọng Làm mốc tham chiếu cho Hiệu quả thanh toán đúng hạn và Công cụ theo dõi phí phạt do thanh toán trễ. Lấy dữ liệu ở đâu Tính bằng: BSEG-ZFBDT (Ngày cơ sở) + BSEG-ZBD1T/ZBD2T/ZBD3T (Số ngày). Thu thập Xác định bằng cách so sánh ngày hiện tại với ngày đến hạn thanh toán ròng Loại sự kiện calculated | |||
| Hóa đơn được lưu tạm | Cho biết hóa đơn đã được nhập vào SAP nhưng chưa hạch toán vào sổ cái, thường dùng cho bước nhập dữ liệu sơ bộ. Trạng thái này được ghi nhận trực tiếp từ bảng VBKPF hoặc bằng cách xác định chứng từ có trạng thái lưu tạm trong BKPF trước khi chuyển sang trạng thái đã hạch toán. | ||
| Vì sao điều này quan trọng Trạng thái lưu tạm đánh dấu thời điểm bắt đầu nhập dữ liệu và giúp đo khoảng trễ từ lúc nhận hóa đơn đến khi phát sinh nghĩa vụ tài chính. Lấy dữ liệu ở đâu Bảng VBKPF chứa dữ liệu phần đầu của chứng từ lưu tạm, hoặc bảng BKPF với trạng thái chứng từ cụ thể (BSTAT = V). Thu thập Ghi nhận khi tạo mục nhập VBKPF Loại sự kiện explicit | |||
| Mất chiết khấu tiền mặt | Sự kiện được tính để đánh dấu ngày hết hạn nhận chiết khấu tiền mặt. Giá trị này được xác định bằng cách so sánh ngày đến hạn chiết khấu với ngày hiện tại hoặc ngày thanh toán. | ||
| Vì sao điều này quan trọng Cần thiết để Công cụ tối ưu chiết khấu thanh toán sớm trực quan hóa các cơ hội tài chính đã bỏ lỡ. Lấy dữ liệu ở đâu Tính bằng: BSEG-ZFBDT + BSEG-ZBD1T (Số ngày chiết khấu 1). Thu thập Xác định bằng cách so sánh ngày hiện tại với ngày đến hạn chiết khấu Loại sự kiện calculated | |||
| Phát hiện chênh lệch giá | Hoạt động suy ra cho biết giá trên hóa đơn không khớp với giá trong đơn đặt hàng. Hoạt động này được xác định khi một Khóa chặn thanh toán cụ thể, thường là 'R' cho Xác minh hóa đơn, được tự động áp dụng sau khi hạch toán. | ||
| Vì sao điều này quan trọng Giúp xác định nguyên nhân gốc rễ của việc làm lại thủ công và hỗ trợ Phân tích tỷ lệ đối chiếu ba bên. Lấy dữ liệu ở đâu Suy ra từ giá trị BSEG-ZLSPR là 'R' (hoặc cấu hình riêng của hệ thống cho lệnh chặn do chênh lệch giá) tại thời điểm hạch toán. Thu thập So sánh giá trị ZLSPR với 'R' Loại sự kiện inferred | |||
| Phát hiện chênh lệch số lượng | Hoạt động suy ra cho biết số lượng trên hóa đơn không khớp với số lượng nhận hàng. Hoạt động này được xác định khi một Khóa chặn thanh toán cụ thể, thường là 'M' cho Chênh lệch số lượng, được áp dụng cho dòng hóa đơn. | ||
| Vì sao điều này quan trọng Rất quan trọng để phân tích hiệu quả đối chiếu và chất lượng dữ liệu chuỗi cung ứng. Lấy dữ liệu ở đâu Suy ra từ giá trị BSEG-ZLSPR là 'M' (hoặc cấu hình riêng của hệ thống cho lệnh chặn do chênh lệch số lượng). Thu thập So sánh giá trị ZLSPR với 'M' Loại sự kiện inferred | |||
Hướng dẫn trích xuất
Các bước
Xác định CDS View cần dùng: Kiểm tra các CDS View tiêu chuẩn của SAP S/4HANA có sẵn hay không. Các view chính cần dùng gồm I_JournalEntry (Header), I_OperationalAcctgDocItem (Items/tương đương BSEG), I_SupplierInvoice (Logistics), I_PaymentProposalItem (F110) và I_ChangeDocument (nhật ký).
Thiết lập quyền người dùng: Đảm bảo người dùng cơ sở dữ liệu hoặc người dùng dịch vụ kỹ thuật có quyền SELECT trên các view DDL SQL liên kết với thực thể CDS. Thông thường, bạn có thể quản lý quyền này qua SAP HANA Studio hoặc ABAP Eclipse Development Tools (ADT).
Chuẩn bị môi trường SQL: Mở giao diện SQL, chẳng hạn SAP HANA Studio, DBeaver kết nối với HANA hoặc trình kết nối process mining hỗ trợ SQL. Phương pháp này giả định bạn có quyền truy cập SQL trực tiếp vào lớp HANA, nơi các CDS View được cung cấp dưới dạng view.
Xác định phạm vi: Chọn Company Code (CompanyCode) và khoảng năm tài chính để giới hạn khối lượng dữ liệu. Bước này rất quan trọng để đảm bảo hiệu năng khi truy vấn view Operational Accounting Document Item.
Thiết lập logic hoạt động: Sao chép truy vấn SQL bên dưới. Truy vấn dùng UNION ALL để kết hợp 14 khối logic riêng biệt thành một cấu trúc event log. Mỗi khối tương ứng với một hoạt động cụ thể, chẳng hạn Invoice Posted hoặc Payment Cleared.
Xử lý chứng từ thay đổi: Truy vấn có các phần xử lý thay đổi điều khoản thanh toán và thao tác chặn. Các phần này dùng view I_ChangeDocument. Nếu view không hoạt động trong phiên bản S/4 của bạn, có thể cần tạo CDS View tùy chỉnh bao bọc các bảng bên dưới (CDHDR/CDPOS).
Kiểm tra sự kiện được tính toán: Xem lại logic cho Invoice Due và Cash Discount Lost. Đây là các sự kiện được tính bằng cách cộng số ngày vào ngày cơ sở trong view mục kế toán vận hành.
Chạy trích xuất: Thực thi truy vấn. Với tập dữ liệu lớn, bạn nên chia nhỏ quá trình trích xuất theo năm tài chính hoặc Company Code để tránh tràn bộ nhớ.
Kiểm tra định dạng ngày giờ: Đảm bảo cột EventTime có định dạng YYYY-MM-DD HH:MM:SS. SAP HANA SQL trả về dấu thời gian có thể cần chuyển đổi kiểu, tùy thuộc vào ứng dụng đích.
Xuất dữ liệu: Lưu kết quả dưới dạng tệp CSV hoặc Parquet. Đảm bảo tên tiêu đề khớp với các cột trong câu lệnh SELECT cuối cùng.
Chuyển đổi để tải lên: Nếu công cụ process mining yêu cầu định dạng CSV cụ thể, chẳng hạn cách ghi ngày tháng riêng, hãy chuyển đổi dữ liệu bằng tập lệnh hậu xử lý hoặc dùng hàm TO_VARCHAR trong SQL.
Kiểm tra lần cuối: Tải một mẫu dữ liệu lên ProcessMind và xác nhận Case ID (Invoice Number) nhóm chính xác mọi hoạt động từ lúc ghi sổ đến khi thanh toán bù trừ.
Cấu hình
- Bộ lọc Company Code: Giới hạn truy vấn vào các đơn vị tổ chức cụ thể (CompanyCode = '1000') để đảm bảo đúng phạm vi và hiệu năng.
- Khoảng ngày: Lọc theo PostingDate hoặc CreationDate, chẳng hạn 12 tháng gần nhất, để kiểm soát khối lượng dữ liệu.
- Loại tài khoản: Lọc I_OperationalAcctgDocItem theo FinancialAccountType = 'K' (Nhà cung cấp) để loại trừ các dòng GL và Khách hàng.
- Kích hoạt CDS View: Đảm bảo các view I_JournalEntry, I_OperationalAcctgDocItem và I_PaymentProposalItem đang hoạt động và được cấp quyền truy cập SQL.
- Hiệu năng nhật ký thay đổi: Truy vấn I_ChangeDocument có thể tốn nhiều tài nguyên. Giới hạn các truy vấn con theo ObjectClass 'BELEG' và tên trường cụ thể như ZLSPR và ZTERM.
Truy vấn mẫu sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Các bước
- Xác nhận bạn có quyền truy cập SQL trực tiếp vào lược đồ SAP HANA chứa ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP và các bảng chứng từ thay đổi liên quan. Thay [Your SAP HANA schema] và thông tin kết nối bằng các giá trị được phê duyệt cho hệ thống của bạn.
- Xác nhận phạm vi hóa đơn và kỳ báo cáo. Đặt [Start date] và [End date] theo định dạng YYYYMMDD, đồng thời cấu hình [Company code filter] thành điều kiện SQL hợp lệ, chẳng hạn BUKRS IN ('1000','2000').
- Kiểm tra phiên bản SAP và cấu hình tại chỗ cho chứng từ tạm ghi sổ, trường trạng thái chương trình thanh toán, loại chứng từ thanh toán và nơi lưu chứng từ thay đổi. Truy vấn dùng các đối tượng nguồn đã được ghi nhận và ánh xạ trường thận trọng, nhưng cần kiểm tra các phần mở rộng tại chỗ và khác biệt giữa các phiên bản trước khi dùng trong môi trường thực tế.
- Chạy truy vấn trên SAP HANA bằng ứng dụng SQL hoặc dịch vụ trích xuất đã được phê duyệt. Truy vấn tạo một hàng sự kiện cho mỗi hoạt động được trích xuất rõ ràng. ProcessMind không suy ra các hoạt động không có trong kết quả.
- Xem lại dữ liệu nguồn và điều chỉnh các điều kiện cấu hình được đánh dấu cho trạng thái tạm ghi sổ, loại chứng từ thanh toán, trạng thái đề xuất và đợt chạy thanh toán, cùng các lớp đối tượng chứng từ thay đổi. Không mở rộng các điều kiện này nếu chưa đối chiếu để loại trừ chứng từ kế toán trùng lặp hoặc không liên quan.
- Kiểm tra phép nối bằng InvoiceNumber, CompanyCode, năm tài chính, số chứng từ kế toán, số nhà cung cấp và khoản mục khi phù hợp. Xác nhận số chứng từ hóa đơn được thể hiện nhất quán giữa BKPF, BSEG, ACDOCA, REGUH và REGUP trong hệ thống đích.
- Đối chiếu các sự kiện được tính toán. Invoice Due được tạo vào ngày đến hạn ròng đã tính. Cash Discount Lost được tạo vào hạn chiết khấu sớm nhất có thể áp dụng nếu chưa thanh toán trước hạn đó. Đây là các hàng được suy ra, cần phân biệt rõ với sự kiện lấy từ bản ghi nguồn.
- Xuất kết quả thành CSV phẳng mã hóa UTF-8 hoặc định dạng bảng khác được ProcessMind hỗ trợ. Giữ nguyên chính xác tên cột InvoiceNumber, Activity, EventTime, SourceSystem và LastDataUpdate. Mỗi hàng tương ứng với một sự kiện, không gộp các hoạt động theo hóa đơn.
- Tải nhật ký sự kiện lên ProcessMind, ánh xạ InvoiceNumber làm mã trường hợp, Activity làm tên hoạt động và EventTime làm dấu thời gian sự kiện. Ánh xạ các cột còn lại thành thuộc tính sự kiện hoặc trường hợp theo cấu hình nhập dữ liệu của ProcessMind.
Cấu hình
- Khoảng ngày: Ban đầu, hãy trích xuất dữ liệu trong khoảng thời gian cuốn chiếu từ 3 đến 6 tháng. Áp dụng nhất quán điều kiện lọc theo ngày ghi sổ, ngày thay đổi và ngày của chương trình thanh toán. Mở rộng khoảng thời gian khi kiểm tra các điều khoản thanh toán dài.
- Schema: Thay [Your SAP HANA schema] bằng schema chứa các đối tượng SAP. Xác nhận môi trường cung cấp các đối tượng phụ thuộc máy khách thông qua schema đã chọn hay cần thêm điều kiện lọc máy khách.
- Lọc theo công ty: Cấu hình [Company code filter] để giới hạn BUKRS ở các mã công ty cần thiết. Áp dụng cùng phạm vi cho BKPF, BSEG, ACDOCA, REGUH, REGUP và nguồn chứng từ thay đổi nếu có các trường tương ứng.
- Lọc chứng từ: Kiểm tra điều kiện lọc loại chứng từ hóa đơn và loại chứng từ thanh toán. Truy vấn có một số ví dụ phổ biến, nhưng loại chứng từ có thể cấu hình và cần khớp với hệ thống đích.
- Hóa đơn tạm giữ: Xác nhận cách thể hiện trạng thái chứng từ tạm giữ trong VBKPF hoặc BKPF. Truy vấn dùng điều kiện lọc trạng thái có thể cấu hình vì mã trạng thái chứng từ tạm giữ có thể khác nhau giữa các phiên bản và cách triển khai.
- Thay đổi thanh toán: Xác nhận loại đối tượng chứng từ thay đổi, tên bảng, tên trường và cách biểu diễn giá trị cho BSEG-ZLSPR và BSEG-ZTERM. Cần kiểm tra cách lưu chứng từ thay đổi và tên trường trong hệ thống đích.
- Chương trình thanh toán: Xác nhận các trường REGUH và REGUP dùng cho trạng thái đề xuất và thực hiện, ngày chạy, mã nhận diện lần chạy và liên kết chứng từ kế toán. Cấu hình chương trình thanh toán tại chỗ có thể ảnh hưởng đến các giá trị trạng thái hiện có.
- Hiệu năng: Giới hạn khoảng ngày và mã công ty, chỉ chọn các cột cần thiết, đồng thời lọc từng nguồn trước khi nối bảng. Với tập dữ liệu lớn, hãy tạo các tập con nguồn đã lọc hoặc dùng HANA calculation view hay schema trích xuất được phê duyệt.
- Quyền truy cập: Cần có quyền đọc các đối tượng trong schema SAP HANA liên quan và mọi view cung cấp dữ liệu kế toán, chương trình thanh toán và chứng từ thay đổi. Hãy phối hợp với nhóm bảo mật SAP và quản trị dữ liệu.
- Điều kiện nghiệp vụ: Các chức năng liên quan đến Kế toán tài chính, Khoản phải trả, chương trình thanh toán và chứng từ thay đổi phải được kích hoạt và có dữ liệu. Nếu cách triển khai không dùng một bảng nguồn, hãy cấu hình nguồn thay thế đã được phê duyệt theo thiết kế hệ thống.
- Xử lý dấu thời gian: BKPF và BSEG thường lưu ngày và giờ ở các trường riêng. Truy vấn kết hợp chúng thành dấu thời gian. Xác nhận múi giờ của hệ thống nguồn và chuyển đổi phù hợp trước khi tải lên ProcessMind.
- Bảo vệ dữ liệu: Giới hạn dữ liệu nhà cung cấp và kế toán trong phạm vi đã được phê duyệt, đồng thời áp dụng chính sách lưu trữ, che dữ liệu và kiểm soát truy cập của tổ chức.
Truy vấn mẫu sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Sẵn sàng bắt đầu?
Biến dữ liệu tài chính thành thông tin hữu ích và bắt đầu tối ưu hóa chu kỳ thanh toán ngay hôm nay. Đội ngũ của chúng tôi sẵn sàng hỗ trợ bạn trong từng bước triển khai process mining.
Tối ưu quy trình xử lý thanh toán khoản phải trả trong SAP S/4HANA
Gỡ bỏ điểm nghẽn và giảm 30% thời gian chu kỳ.
Không cần thẻ tín dụng. Thiết lập trong 5 phút.