Mẫu dữ liệu cho quy trình ghi nhận đến báo cáo, bút toán nhật ký
Mẫu dữ liệu cho quy trình ghi nhận đến báo cáo, bút toán nhật ký
- 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 thực tế
Thuộc tính của quy trình ghi nhận đến báo cáo, bút toán nhật ký
| Tên | Mô tả | ||
|---|---|---|---|
| Hoạt động ActivityName | Tên hoạt động nghiệp vụ diễn ra tại một thời điểm cụ thể trong quy trình bút toán. | ||
| Mô tả Hoạt động là một bước hoặc sự kiện cụ thể trong vòng đời của bút toán, chẳng hạn như 'Đã tạo bút toán', 'Đã gửi bút toán để rà soát' hoặc 'Đã ghi sổ bút toán'. Các hoạt động này thường được xác định từ nhật ký thay đổi, cập nhật trạng thái hoặc mã giao dịch được ghi trong hệ thống. Phân tích hoạt động giúp trực quan hóa luồng quy trình, xác định các luồng xử lý phổ biến và phát hiện sai lệch so với quy trình chuẩn. Đây là cơ sở để tính các chỉ số như tần suất hoạt động, thời gian chờ giữa các bước và tỷ lệ tuân thủ. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong quy trình, giúp trực quan hóa sơ đồ quy trình và phân tích các mẫu trong quy trình làm việc. Lấy dữ liệu ở đâu Được xác định từ nhiều nguồn, bao gồm trường trạng thái trong bảng tiêu đề hoặc dòng bút toán, chẳng hạn BKPF-BSTAT, nhật ký thay đổi chứng từ (CDHDR/CDPOS) và nhật ký workflow. Ví dụ Đã tạo bút toánĐã tạm lưu bút toánĐã gửi bút toán để rà soátBút toán đã được phê duyệtĐã ghi sổ bút toán | |||
| Mã bút toán JournalEntryId | Mã định danh duy nhất của một bút toán tài chính, được dùng làm mã hồ sơ chính của quy trình. | ||
| Mô tả Mã bút toán là số duy nhất được gán cho mỗi chứng từ kế toán khi tạo trong SAP S/4HANA. Mã này rất cần thiết để theo dõi toàn bộ vòng đời của bút toán, từ lúc tạo hoặc tạm lưu, qua các bước phê duyệt, đến khi ghi sổ và có thể bị đảo hoặc tất toán. Trong phân tích process mining, mã này được dùng để liên kết mọi hoạt động liên quan thành một hồ sơ duy nhất. Bằng cách nhóm các sự kiện theo cùng một mã bút toán, chuyên viên phân tích có thể tái dựng luồng quy trình từ đầu đến cuối, đo thời gian xử lý và xác định các biến thể hoặc điểm nghẽn của từng giao dịch tài chính. Đây là thuộc tính nền tảng để xây dựng toàn bộ góc nhìn về quy trình. Vì sao điều này quan trọng Mã này liên kết mọi bước liên quan trong quy trình, giúp bạn phân tích toàn bộ hành trình của từng bút toán. Lấy dữ liệu ở đâu Đây là khóa ghép, thường được tạo bằng cách nối Mã công ty (BKPF-BUKRS), Số chứng từ (BKPF-BELNR) và Năm tài chính (BKPF-GJAHR). Ví dụ 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Thời điểm sự kiện EventTime | Dấu thời gian cho biết một hoạt động cụ thể của bút toán diễn ra khi nào. | ||
| Mô tả Thời điểm sự kiện là ngày giờ chính xác khi một hoạt động nghiệp vụ được thực hiện và ghi nhận trong hệ thống. Mỗi hoạt động trong một hồ sơ có dấu thời gian riêng, tạo thành chuỗi sự kiện theo thứ tự thời gian. Thuộc tính này rất quan trọng đối với mọi phân tích quy trình dựa trên thời gian. Thuộc tính được dùng để tính thời gian xử lý, khoảng thời gian giữa các hoạt động và thời gian chờ, đồng thời giúp hiểu cách công việc phân bố theo thời gian. Dấu thời gian chính xác là điều kiện cần để xây dựng mô hình quy trình đáng tin cậy và tính các chỉ số hiệu suất quan trọng như Thời gian chu kỳ phê duyệt. 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, cần thiết để tính mọi chỉ số về thời lượng và hiểu tiến trình của quy trình. Lấy dữ liệu ở đâu Lấy từ nhật ký thay đổi chứng từ (CDHDR-UDATE, CDHDR-UTIME), nhật ký workflow hoặc dấu thời gian tạo/nhập trên các bảng như BKPF (CPUDT, CPUTM). Ví dụ 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Loại bút toán JournalEntryType | Phân loại bút toán theo mục đích nghiệp vụ, chẳng hạn ghi nhận tài sản, hóa đơn nhà cung cấp hoặc bút toán sổ cái. | ||
| Mô tả Loại bút toán, còn gọi là loại chứng từ theo thuật ngữ SAP, là mã dùng để phân loại chứng từ kế toán. Mã này quy định các yếu tố như dải số được gán cho chứng từ và loại tài khoản được phép ghi sổ. Phân tích quy trình theo loại bút toán rất quan trọng để hiểu cách xử lý trong từng bối cảnh. Ví dụ, quy trình phê duyệt khoản trích trước đơn giản (loại SA) có thể ít bước hơn nhiều so với quy trình mua tài sản phức tạp (loại AA). Đây là chiều phân tích chính của dashboard 'Tuân thủ theo loại bút toán'. Vì sao điều này quan trọng Phân loại bút toán theo bối cảnh nghiệp vụ, giúp phân tích khác biệt và hiệu suất quy trình giữa các loại giao dịch tài chính. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường BLART (Loại chứng từ). Ví dụ SAKRAA | |||
| Mã công ty CompanyCode | Mã định danh duy nhất của công ty hoặc pháp nhân ghi nhận bút toán. | ||
| Mô tả Mã công ty là đơn vị tổ chức cơ bản trong SAP Financials, đại diện cho một pháp nhân độc lập lập báo cáo tài chính. Mỗi bút toán được gán cho một mã công ty cụ thể. Thuộc tính này rất quan trọng để phân nhóm và so sánh hiệu quả quy trình giữa các bộ phận trong tổ chức. Chuyên viên phân tích có thể lọc chế độ xem quy trình theo pháp nhân, so sánh tỷ lệ bị từ chối giữa các mã công ty hoặc tìm ra khác biệt trong quy trình theo từng khu vực. Vì sao điều này quan trọng Cho phép lọc và so sánh quy trình ghi nhận bút toán giữa các pháp nhân hoặc đơn vị kinh doanh trong tổ chức. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường BUKRS (Mã công ty). Ví dụ 10001710US01 | |||
| Ngày ghi sổ PostingDate | Ngày bút toán được ghi vào sổ cái, ảnh hưởng đến kỳ tài chính. | ||
| Mô tả Ngày ghi sổ xác định kỳ tài chính mà giao dịch xuất hiện trên báo cáo tài chính. Đây là ngày quan trọng trong kế toán và có thể khác ngày tạo chứng từ hoặc nhập chứng từ vào hệ thống. Trong process mining, ngày ghi sổ được dùng để phân tích nhóm theo thời gian, chẳng hạn so sánh quy trình khóa sổ cuối tháng hoặc theo dõi xu hướng hiệu suất qua các kỳ tài chính. Ngày này cũng giúp đo độ trễ giữa lúc tạo bút toán và lúc thực sự ghi sổ. Vì sao điều này quan trọng Cung cấp bối cảnh tài chính quan trọng, giúp phân tích hiệu suất quy trình trong từng kỳ kế toán, chẳng hạn cuối tháng hoặc cuối năm. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường BUDAT (Ngày ghi sổ trong chứng từ). Ví dụ 2023-10-312023-11-012024-02-29 | |||
| Người dùng tạo CreatedByUser | ID người dùng đã tạo bút toán. | ||
| Mô tả Thuộc tính này lưu mã định danh duy nhất của người dùng khởi tạo quy trình tạo bút toán bằng cách lập chứng từ ban đầu. Đó có thể là kế toán, người dùng nghiệp vụ hoặc ID hệ thống dùng cho các bút toán tự động. Phân tích quy trình theo người tạo giúp nhận diện các xu hướng gắn với từng người dùng hoặc nhóm. Chẳng hạn, bạn có thể phát hiện nhu cầu đào tạo nếu một số người dùng có tỷ lệ bị từ chối cao, hoặc nhận ra những cá nhân có hiệu suất tốt. Đây là thuộc tính thiết yếu cho dashboard 'Hoạt động và năng suất người dùng'. Vì sao điều này quan trọng Gắn 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, cân bằng khối lượng công việc và xác định nhu cầu đào tạo. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường USNAM (Tên người dùng). Ví dụ ABROWNCJONESBATCH_USER | |||
| Số tiền theo nội tệ AmountInLocalCurrency | Tổng giá trị bút toán tính theo nội tệ của mã công ty. | ||
| Mô tả Thuộc tính này thể hiện giá trị tài chính của bút toán. Thông thường, giá trị được tính bằng tổng trị tuyệt đối của các khoản ghi nợ hoặc ghi có trong chứng từ, quy đổi sang nội tệ của mã công ty. Phân tích theo số tiền giúp phân nhóm quy trình dựa trên tác động tài chính. Ví dụ, bút toán giá trị lớn có thể cần quy trình phê duyệt chặt chẽ hơn bút toán giá trị nhỏ. Nhờ đó, bạn có thể ưu tiên cải tiến quy trình ở những giao dịch có rủi ro tài chính cao nhất. Vì sao điều này quan trọng Cho biết giá trị tài chính của bút toán, giúp phân tích cách quy trình thay đổi tùy theo số tiền liên quan. Lấy dữ liệu ở đâu Được tính bằng cách cộng các khoản tiền trong bảng chi tiết BSEG (trường DMBTR) của một bút toán (BELNR), sau đó chuyển thành giá trị dương. Ví dụ 1500.75125000.0050.20 | |||
| Có làm lại IsRework | Cờ boolean cho biết bút toán có phải làm lại hay không, chẳng hạn được sửa sau khi bị từ chối. | ||
| Mô tả Thuộc tính được tính toán này đánh dấu các bút toán đi lệch khỏi quy trình lý tưởng. Giá trị thường được đặt thành true nếu trong trường hợp có hoạt động như 'Bút toán bị từ chối' hoặc 'Bút toán được sửa'. Cờ này giúp phân tích hiệu quả quy trình dễ dàng hơn. Bạn có thể nhanh chóng tính KPI Tỷ lệ làm lại và so sánh trực tiếp thời gian chu kỳ cũng như chi phí giữa các trường hợp có và không phải làm lại. Tìm ra nguyên nhân dẫn đến việc làm lại là mục tiêu chính của nhiều sáng kiến cải tiến quy trình. Vì sao điều này quan trọng Đánh dấu các trường hợp cần sửa hoặc phải lặp lại bước, giúp dễ dàng đo lường và tìm nguyên nhân gốc rễ của những điểm chưa hiệu quả trong quy trình. Lấy dữ liệu ở đâu Đây là thuộc tính được tính từ chuỗi hoạt động trong một trường hợp. Thuộc tính được đánh dấu là 'true' nếu có hoạt động như 'Bút toán bị từ chối'. Ví dụ truefalse | |||
| Ghi sổ thủ công IsManualPosting | Cờ boolean cho biết bút toán có được người dùng ghi sổ thủ công hay không. | ||
| Mô tả Thuộc tính này xác định các bút toán được ghi sổ do người dùng thao tác, thay vì được ghi tự động bởi tác vụ hệ thống hoặc giao diện tích hợp. Thuộc tính thường được xác định dựa trên Mã giao dịch dùng để ghi chứng từ. Cờ này được dùng để tính KPI Tỷ lệ ghi sổ thủ công và theo dõi tiến độ tự động hóa quy trình Record to Report. Khi lọc các bút toán được ghi sổ thủ công, chuyên viên phân tích có thể xác định những trường hợp vẫn cần người xử lý và đánh giá khả năng tự động hóa. Vì sao điều này quan trọng Phân biệt bút toán do người dùng và hệ thống ghi sổ, giúp đo mức độ tự động hóa và xác định cơ hội tự động hóa. Lấy dữ liệu ở đâu Đây là thuộc tính được tính từ TransactionCode. Danh sách mã giao dịch thủ công được xác định trước, chẳng hạn 'FB01', 'F-02', sẽ được dùng để đặt cờ thành 'true'. Ví dụ truefalse | |||
| Hệ thống nguồn SourceSystem | Xác định hệ thống nguồn nơi trích xuất dữ liệu bút toán. | ||
| Mô tả Thuộc tính này cho biết hệ thống ghi nhận dữ liệu gốc của bút toán. Với doanh nghiệp sử dụng nhiều hệ thống ERP hoặc kết hợp hệ thống cũ và mới, thuộc tính này giúp phân biệt nguồn dữ liệu. Khi phân tích, bạn có thể dùng thuộc tính này để so sánh hiệu quả quy trình giữa các hệ thống hoặc lọc dữ liệu theo một nguồn cụ thể. Đây cũng là thông tin quan trọng để quản trị dữ liệu và hiểu đúng bối cảnh của dữ liệu. Vì sao điều này quan trọng Cho biết nguồn gốc dữ liệu, giúp phân tích và so sánh quy trình chính xác khi doanh nghiệp sử dụng nhiều hệ thống. Lấy dữ liệu ở đâu Đây thường là giá trị tĩnh được thêm trong quá trình trích xuất dữ liệu, dùng để xác định phiên bản SAP S/4HANA cụ thể, chẳng hạn như SID hoặc tên hệ thống logic. Ví dụ S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian cho biết lần gần nhất dữ liệu của bản ghi này được làm mới từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này ghi lại ngày giờ lần gần nhất dữ liệu được trích xuất hoặc cập nhật từ hệ thống nguồn. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến mức nào. Thời điểm cập nhật gần nhất giúp bạn hiểu dữ liệu phân tích quy trình còn hiện hành hay không. Thông tin này cũng giúp bạn đọc đúng dashboard và KPI, biết dữ liệu gần như theo thời gian thực hay chỉ là ảnh chụp của một kỳ trước. Vì sao điều này quan trọng Cho biết dữ liệu mới đến mức nào, giúp người dùng nắm được thời điểm của dữ liệu phân tích quy trình. Lấy dữ liệu ở đâu Đây là thuộc tính siêu dữ liệu, thường được tạo và ghi dấu thời gian vào từng bản ghi trong quy trình nạp dữ liệu. Ví dụ 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Lý do đảo bút toán ReversalReason | Mã cho biết lý do đảo một bút toán đã ghi sổ. | ||
| Mô tả Nếu bút toán đã ghi sổ có sai sót, bạn không thể xóa mà phải đảo bút toán bằng một chứng từ mới. Mã lý do đảo giải thích vì sao cần thực hiện thao tác này, chẳng hạn ngày ghi sổ hoặc số tiền không chính xác. Phân tích lý do đảo giúp tìm nguyên nhân gốc rễ của lỗi trong quy trình Record to Report. Nếu một lý do xuất hiện thường xuyên, có thể quy trình đang gặp vấn đề mang tính hệ thống, chẳng hạn đào tạo chưa đầy đủ hoặc thiếu kiểm soát. Cần xử lý những vấn đề này để nâng cao chất lượng ngay từ lần đầu. Vì sao điều này quan trọng Giúp tìm nguyên nhân gốc rễ của lỗi dẫn đến đảo bút toán, từ đó giảm việc làm lại và nâng cao chất lượng quy trình. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường STGRD (Lý do đảo bút toán). Ví dụ 010205 | |||
| Mã giao dịch TransactionCode | Mã giao dịch SAP dùng để tạo hoặc thay đổi bút toán. | ||
| Mô tả Mã giao dịch (T-Code) là lối tắt để mở một chức năng hoặc chương trình cụ thể trong SAP. Với bút toán, các T-Code khác nhau có thể cho biết cách tạo bút toán, chẳng hạn FB01 để ghi sổ cái thủ công, FV50 để lưu tạm hoặc mã tự động dành cho bút toán do hệ thống tạo. Thuộc tính này cho biết hoạt động do người dùng thực hiện thủ công hay do hệ thống tự động. Đây là thông tin quan trọng để tính KPI Tỷ lệ ghi sổ thủ công và xác định cơ hội tự động hóa. Vì sao điều này quan trọng Cho biết bút toán được xử lý theo cách nào, chẳng hạn thủ công hay tự động. Đây là thông tin quan trọng để phân tích tự động hóa và hiểu khác biệt trong quy trình. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường TCODE (Mã giao dịch). Ví dụ FB01FV50F-02 | |||
| Năm tài chính FiscalYear | Năm tài chính mà bút toán thuộc về. | ||
| Mô tả Năm tài chính là một phần của khóa duy nhất xác định bút toán, cùng với mã công ty và số chứng từ. Thuộc tính này cho biết năm tài chính mà chứng từ có liên quan. Khi phân tích, năm tài chính được dùng để theo dõi xu hướng dài hạn và đảm bảo mã định danh trường hợp là duy nhất. So sánh các chỉ số quy trình giữa những năm tài chính khác nhau có thể cho thấy hiệu suất đã cải thiện hay giảm sút theo thời gian. Vì sao điều này quan trọng Cung cấp thành phần quan trọng để xác định duy nhất chứng từ và phân tích hiệu suất quy trình qua từng năm. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường GJAHR (Năm tài chính). Ví dụ 202320242022 | |||
| Người phê duyệt ApproverUser | ID người dùng đã phê duyệt hoặc từ chối bút toán. | ||
| Mô tả Thuộc tính này xác định người dùng chịu trách nhiệm xem xét và quyết định đối với bút toán được gửi. Trong quy trình làm việc có nhiều cấp phê duyệt, một bút toán có thể có nhiều người phê duyệt. Thông tin này cần thiết để phân tích chi tiết quy trình phê duyệt. Bạn có thể dùng thông tin này để đo khối lượng công việc của từng người phê duyệt, tính thời gian phê duyệt của mỗi người và tìm điểm nghẽn trong chuỗi phê duyệt. Thuộc tính này hỗ trợ trực tiếp cho dashboard 'Hoạt động và năng suất người dùng'. Vì sao điều này quan trọng Xác định người chịu trách nhiệm phê duyệt, giúp phân tích khối lượng công việc, hiệu suất và điểm nghẽn trong khâu phê duyệt. Lấy dữ liệu ở đâu Lấy từ nhật ký quy trình làm việc, chẳng hạn SWW_WI2OBJ, SWWLOG, hoặc bảng tài liệu thay đổi CDHDR/CDPOS bằng cách theo dõi người thực hiện bước phê duyệt. Ví dụ DMILLERFWHITEKCHEN | |||
| Thời điểm kết thúc EndTime | Dấu thời gian cho biết hoạt động hoàn tất khi nào. | ||
| Mô tả Thời điểm kết thúc đánh dấu lúc một hoạt động hoàn tất. Trong nhiều nhật ký sự kiện, thời điểm bắt đầu và kết thúc của hoạt động giống nhau, nghĩa là sự kiện diễn ra tức thời. Nhưng với hoạt động có thời lượng đo được, chẳng hạn người dùng trực tiếp xem xét tài liệu, thuộc tính này có thể ghi lại khoảng thời gian đó. Có thời điểm kết thúc riêng giúp tính chính xác hơn thời gian xử lý hoạt động và thời gian chờ. Nhờ đó, bạn phân biệt được lúc một tác vụ đang được xử lý với lúc tác vụ nằm chờ trong hàng đợi. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý hoạt động và phân biệt thời gian làm việc thực tế với thời gian chờ. Lấy dữ liệu ở đâu Với sự kiện tức thời, giá trị này thường trùng với StartTime. Với hoạt động có thời lượng, dữ liệu có thể lấy từ nhật ký quy trình làm việc hoặc được tính dựa trên các sự kiện tiếp theo. Ví dụ 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Thời gian chu kỳ phê duyệt ApprovalCycleTime | Khoảng thời gian từ lúc gửi bút toán để phê duyệt đến khi bút toán được phê duyệt hoặc từ chối. | ||
| Mô tả Chỉ số được tính toán này tập trung vào thời lượng của giai đoạn phê duyệt. Chỉ số đo khoảng thời gian từ hoạt động 'Bút toán được gửi để xem xét' đến hoạt động tiếp theo là 'Bút toán được phê duyệt' hoặc 'Bút toán bị từ chối'. KPI này rất quan trọng để tìm điểm nghẽn trong quy trình làm việc phê duyệt. Thời gian chu kỳ phê duyệt dài có thể làm chậm đáng kể toàn bộ quy trình. Phân tích chỉ số theo người phê duyệt, mã công ty hoặc loại bút toán có thể giúp xác định những khâu cần cải thiện. Vì sao điều này quan trọng Đo riêng thời lượng của bước phê duyệt, giúp xác định và xử lý điểm nghẽn trong quy trình xem xét, phê duyệt. Lấy dữ liệu ở đâu Được tính bằng chênh lệch thời gian giữa sự kiện 'Bút toán được gửi để xem xét' và sự kiện 'Bút toán được phê duyệt' hoặc 'Bút toán bị từ chối'. Ví dụ 1 ngày 2 giờ4 giờ 25 phút5 ngày 0 giờ | |||
| Trạng thái chứng từ DocumentStatus | Trạng thái xử lý hiện tại của bút toán, chẳng hạn lưu tạm, đã ghi sổ hoặc đã tất toán. | ||
| Mô tả Trạng thái chứng từ cho biết bút toán đang ở giai đoạn nào trong vòng đời. Ví dụ, chứng từ 'lưu tạm' đã được lưu nhưng chưa ghi vào sổ cái, còn chứng từ 'đã ghi sổ' đã hoàn tất. Phân tích trạng thái giúp bạn hiểu luồng công việc và tìm điểm nghẽn. Nếu nhiều chứng từ ở trạng thái 'lưu tạm' hoặc 'chờ phê duyệt' trong thời gian dài, đó có thể là dấu hiệu quy trình chưa hiệu quả. Trạng thái cũng là nguồn dữ liệu quan trọng để xác định các hoạt động trong quy trình. Vì sao điều này quan trọng Cho biết bút toán đang ở giai đoạn nào, giúp phát hiện hàng đợi và điểm nghẽn. Lấy dữ liệu ở đâu Bảng BKPF trong SAP S/4HANA, trường BSTAT (Trạng thái chứng từ). Ví dụ VAB | |||
Hoạt động trong quy trình ghi nhận đến báo cáo, bút toán nhật ký
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Bút toán đã được phê duyệt | Bút toán được quản lý có thẩm quyền phê duyệt lần cuối, xác nhận tính hợp lệ và chính xác. Đây là bước kiểm soát cuối cùng trước khi chứng từ được ghi sổ vào sổ cái tổng hợp. | ||
| Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu kết thúc chu kỳ phê duyệt. Thời gian để đạt đến bước này chiếm phần lớn tổng thời gian xử lý và là chỉ số quan trọng về hiệu quả của người phê duyệt. Lấy dữ liệu ở đâu Sự kiện này được suy ra từ nhật ký workflow ghi nhận bước phê duyệt cuối cùng hoặc thay đổi trạng thái trên chứng từ. Có thể lấy mã người dùng của người phê duyệt và dấu thời gian từ dữ liệu workflow hoặc nhật ký thay đổi. Thu thập Xác định dấu thời gian của bước phê duyệt cuối cùng trong nhật ký workflow hoặc thời điểm trạng thái chuyển thành 'Đã phê duyệt' trong nhật ký thay đổi chứng từ. Loại sự kiện inferred | |||
| Đã ghi sổ bút toán | Bút toán được ghi chính thức vào sổ cái tổng hợp và ảnh hưởng đến báo cáo tài chính của công ty. Từ thời điểm này, chứng từ trở thành bản ghi tài chính chính thức. | ||
| Vì sao điều này quan trọng Đây là cột mốc chính đánh dấu hoàn tất chu kỳ xử lý cốt lõi. Phân tích số lượng bút toán được ghi sổ và thời gian để đạt đến bước này là các chỉ số cơ bản trong process mining. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ ràng bằng Ngày ghi sổ (BUDAT) trong bảng BKPF. Chứng từ đã ghi sổ có trạng thái chứng từ (BSTAT) để trống, khác với chứng từ tạm lưu ('V') hoặc chứng từ đang giữ ('D'). Thu thập Dùng Ngày ghi sổ (BKPF-BUDAT) và Ngày nhập (BKPF-CPUDT) làm dấu thời gian của sự kiện. BKPF-BSTAT để trống cho biết chứng từ đã được ghi sổ. Loại sự kiện explicit | |||
| Đã gửi bút toán để rà soát | Người tạo bút toán chính thức gửi chứng từ vào quy trình rà soát và phê duyệt. Hoạt động này đánh dấu bước chuyển từ nhập dữ liệu sang quy trình kiểm soát chính thức, đồng thời bắt đầu chu kỳ phê duyệt. | ||
| Vì sao điều này quan trọng Đây là thời điểm bắt đầu tính chu kỳ phê duyệt. Đo thời gian từ đây đến khi bút toán được phê duyệt hoặc từ chối giúp xác định điểm nghẽn riêng trong các giai đoạn rà soát và phê duyệt. Lấy dữ liệu ở đâu Sự kiện này thường được ghi nhận trong nhật ký workflow (các bảng SWW_WIHEAD, SWWLOG) liên kết với đối tượng nghiệp vụ. Bạn cũng có thể suy ra sự kiện từ thay đổi trạng thái trong trường tùy chỉnh trên tiêu đề chứng từ (BKPF). Thu thập Dấu thời gian tạo mục workflow hoặc thời điểm trường trạng thái chuyển thành 'Đã gửi' hoặc 'Đang rà soát'. Loại sự kiện inferred | |||
| Đã tạo bút toán | Hoạt động này đánh dấu thời điểm tạo chứng từ bút toán trong hệ thống. Bản ghi được tạo trong bảng tiêu đề (BKPF), nhưng chưa được ghi sổ vào sổ cái tổng hợp. Đây là điểm bắt đầu vòng đời của bút toán. | ||
| Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của quy trình. Phân tích thời gian từ sự kiện này đến lúc ghi sổ rất quan trọng để đo tổng thời gian xử lý và xác định chậm trễ ở khâu nhập dữ liệu ban đầu. Lấy dữ liệu ở đâu Có thể ghi nhận trực tiếp sự kiện này từ bảng BKPF trong SAP bằng các trường ngày tạo (CPUDT) và giờ tạo (CPUTM) của một số chứng từ (BELNR) cụ thể. Thu thập Dùng BKPF-CPUDT và BKPF-CPUTM làm dấu thời gian của sự kiện. Loại sự kiện explicit | |||
| Đã tất toán bút toán | Một khoản mục chưa tất toán trong bút toán được bù trừ bằng một lần ghi sổ khác, chẳng hạn khoản thanh toán dùng để tất toán hóa đơn. Hoạt động này đánh dấu việc đối chiếu các dòng bút toán cụ thể và hoàn tất chúng. | ||
| Vì sao điều này quan trọng Với nhiều bút toán, đặc biệt là bút toán liên quan đến tài khoản tạm giữ hoặc tài khoản quản lý theo khoản mục chưa tất toán, đây là bước đối chiếu cuối cùng. Phân tích thời gian từ lúc ghi sổ đến khi tất toán giúp đo lường hiệu quả đối chiếu. Lấy dữ liệu ở đâu Sự kiện này được suy ra từ bảng dòng bút toán (BSEG hoặc chế độ xem ACDOCA). Khi một khoản mục được tất toán, các trường Ngày tất toán (AUGDT) và Chứng từ tất toán (AUGBL) của dòng đó sẽ được điền. Thu thập Dùng ngày tất toán (BSEG-AUGDT) của dòng bút toán làm dấu thời gian cho sự kiện. Loại sự kiện inferred | |||
| Đã xử lý đảo bút toán | Một bút toán đã ghi sổ trước đó được đảo bằng cách tạo chứng từ mới với các bút toán ngược. Đây là thao tác rõ ràng, có thể kiểm toán, được thực hiện để sửa lỗi trong chứng từ đã ghi sổ. | ||
| Vì sao điều này quan trọng Bút toán đảo cho thấy đã xảy ra lỗi trong chứng từ được ghi sổ. Tỷ lệ đảo cao có thể phản ánh vấn đề tiềm ẩn trong quy trình phê duyệt hoặc chất lượng nhập dữ liệu. Theo dõi chỉ số này giúp nâng cao độ chính xác ngay từ lần đầu. Lấy dữ liệu ở đâu Đảo bút toán là sự kiện được ghi nhận rõ ràng. Tiêu đề (BKPF) của chứng từ đảo mới có tham chiếu đến chứng từ gốc trong trường Số chứng từ bị đảo (STBLG). Ngày ghi sổ của chứng từ mới là thời điểm xảy ra sự kiện. Thu thập Xác định các chứng từ có BKPF-STBLG được điền. Dấu thời gian của sự kiện là ngày ghi sổ của chứng từ đảo. Loại sự kiện explicit | |||
| Bút toán bị thay đổi sau khi ghi sổ | Người dùng sửa một số trường giới hạn trên bút toán sau khi bút toán đã được ghi vào sổ cái tổng hợp. Dù phần lớn dữ liệu tài chính không thể thay đổi sau khi ghi sổ, một số trường như nội dung hoặc phân công vẫn có thể được sửa. | ||
| Vì sao điều này quan trọng Hoạt động này là dấu hiệu quan trọng về tuân thủ. Thay đổi sau khi ghi sổ có thể cho thấy có ý định sửa hồ sơ, vì vậy cần theo dõi chặt chẽ để ngăn gian lận và bảo đảm tính toàn vẹn của dữ liệu. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này một cách đáng tin cậy từ các bảng nhật ký thay đổi chứng từ (CDHDR và CDPOS). Bản ghi trong CDHDR cho số chứng từ có ngày thay đổi sau ngày ghi sổ cho thấy chứng từ đã bị sửa sau khi ghi sổ. Thu thập Tìm các bản ghi trong CDHDR có dấu thời gian thay đổi (UDATE/UTIME) sau ngày ghi sổ của chứng từ (BKPF-BUDAT). Loại sự kiện inferred | |||
| Bút toán bị từ chối | Người rà soát hoặc phê duyệt từ chối bút toán, khiến chứng từ không thể được ghi sổ. Thông thường, chứng từ được gửi lại cho người tạo để chỉnh sửa, bắt đầu một vòng làm lại. | ||
| Vì sao điều này quan trọng Theo dõi các trường hợp bị từ chối là điều cần thiết để hiểu chất lượng quy trình và xác định lỗi phổ biến. Tỷ lệ bị từ chối cao cho thấy có vấn đề về độ chính xác của dữ liệu, mức độ hiểu chính sách hoặc chứng từ hỗ trợ chưa đầy đủ. Lấy dữ liệu ở đâu Sự kiện này được suy ra từ thay đổi trạng thái trong nhật ký workflow hoặc trường trạng thái tùy chỉnh trên chứng từ bút toán. Nhật ký thay đổi chứng từ (CDHDR/CDPOS) của trường trạng thái liên quan có thể cung cấp dấu thời gian. Thu thập Xác định thời điểm trường trạng thái chuyển thành 'Bị từ chối' qua nhật ký thay đổi chứng từ (CDHDR/CDPOS) hoặc nhật ký workflow. Loại sự kiện inferred | |||
| Đã chỉnh sửa bút toán | Người dùng chỉnh sửa bút toán sau khi bị từ chối hoặc được yêu cầu sửa đổi. Hoạt động này thể hiện công sức làm lại để xử lý các vấn đề được phát hiện trong quá trình rà soát trước khi gửi lại. | ||
| Vì sao điều này quan trọng Hoạt động này giúp đo lường các vòng làm lại. Phân tích tần suất và thời gian chỉnh sửa giúp xác định nguồn gây kém hiệu quả, đồng thời tìm ra cơ hội đào tạo và làm rõ quy trình. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này bằng cách theo dõi ngày 'Last Changed On' (AEDAT) trong bảng BKPF của chứng từ trước đó ở trạng thái 'Bị từ chối'. Nhật ký thay đổi chứng từ cung cấp thông tin cụ thể hơn về nội dung đã sửa. Thu thập Dùng dấu thời gian trong tiêu đề nhật ký thay đổi chứng từ (CDHDR-UDATE) cho các thay đổi sau khi bút toán bị từ chối. Loại sự kiện inferred | |||
| Đã đính kèm chứng từ hỗ trợ | Người dùng đính kèm một hoặc nhiều chứng từ hỗ trợ, chẳng hạn như hóa đơn hoặc bảng tính, vào bút toán. Việc này thường nhằm cung cấp bằng chứng và thông tin liên quan đến giao dịch tài chính trong quá trình rà soát và kiểm toán. | ||
| Vì sao điều này quan trọng Đính kèm chứng từ trước khi rà soát là điều cần thiết để bảo đảm tuân thủ và phê duyệt hiệu quả. Hoạt động này giúp đo lường mức độ tuân thủ chính sách về chứng từ và ảnh hưởng của việc đó đến thời gian phê duyệt. Lấy dữ liệu ở đâu Thông thường, sự kiện này được suy ra từ dấu thời gian tạo tệp đính kèm liên kết qua Generic Object Services (GOS). Bảng SRGBTBREL liên kết đối tượng nghiệp vụ, chẳng hạn chứng từ BKPF, với tệp đính kèm. Thu thập Truy vấn các bảng tệp đính kèm GOS, chẳng hạn SRGBTBREL, để tìm liên kết đến đối tượng BKPF và dùng dấu thời gian tạo tệp đính kèm. Loại sự kiện inferred | |||
| Đã tạm lưu bút toán | Người dùng lưu bút toán chưa hoàn chỉnh mà chưa ghi sổ để có thể hoàn tất hoặc rà soát sau. Đây là thao tác rõ ràng, tạo bản ghi tiêu đề chứng từ có trạng thái 'tạm lưu' và chưa được ghi sổ. | ||
| Vì sao điều này quan trọng Tạm lưu là bước thường gặp trước khi gửi bút toán. Theo dõi thời gian ở trạng thái này giúp phát hiện chậm trễ trong khâu hoàn thiện và chuẩn bị dữ liệu trước khi bắt đầu rà soát, phê duyệt chính thức. Lấy dữ liệu ở đâu Trong bảng BKPF, chứng từ tạm lưu được nhận diện bằng trường trạng thái chứng từ (BSTAT) có giá trị 'V'. Dấu thời gian của sự kiện là ngày tạo (CPUDT). Thu thập Lọc các chứng từ có BKPF-BSTAT = 'V' tại thời điểm tạo. Loại sự kiện explicit | |||
| Đã xác định ghi sổ thủ công | Bút toán được ghi sổ bằng mã giao dịch thủ công thay vì qua giao diện tự động hoặc tác vụ xử lý hàng loạt. Đây không phải sự kiện theo thời gian mà là cách phân loại hoạt động ghi sổ. | ||
| Vì sao điều này quan trọng Xác định các bút toán ghi sổ thủ công là việc cần thiết cho các sáng kiến tự động hóa. Tỷ lệ ghi sổ thủ công cao cho thấy có thể đơn giản hóa quy trình bằng cách tích hợp các hệ thống con hoặc dùng chương trình ghi sổ tự động. Lấy dữ liệu ở đâu Việc này được xác định bằng cách phân tích trường mã giao dịch (TCODE) trong bảng tiêu đề chứng từ (BKPF). Danh sách mã giao dịch thủ công đã biết, chẳng hạn FB01, F-02, FB50, được dùng để phân loại bút toán. Thu thập Phân loại sự kiện dựa trên BKPF-TCODE và danh sách mã giao dịch thủ công đã định trước tại thời điểm ghi sổ. Loại sự kiện calculated | |||
Hướng dẫn trích xuất
Các bước
- Điều kiện tiên quyết và quyền truy cập: Đảm bảo bạn có tài khoản với đủ quyền để truy vấn cơ sở dữ liệu bên dưới của SAP S/4HANA hoặc chạy báo cáo ABAP. Bạn cần quyền đọc các CDS view I_JournalEntry, I_JournalEntryItem và các bảng CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ, SWWLOGHIST. Thông thường, bạn có thể truy cập bằng ứng dụng cơ sở dữ liệu như SAP HANA Studio, DBeaver hoặc SAP ABAP Development Tools (ADT) cho Eclipse.
- Xác định cấu hình riêng của hệ thống: Trước khi chạy truy vấn, hãy xác định mã nhiệm vụ cụ thể dùng trong quy trình phê duyệt bút toán nhật ký. Hỏi quản trị viên SAP workflow để biết ID nhiệm vụ (chẳng hạn TS12345678) tương ứng với các sự kiện gửi, từ chối và phê duyệt. Bạn cần các mã này để điền vào chỗ giữ chỗ trong truy vấn cuối cùng.
- Chuẩn bị truy vấn SQL: Sao chép toàn bộ truy vấn SQL trong phần
queryvào ứng dụng SQL hoặc công cụ phát triển bạn chọn. - Đặt tham số truy vấn: Tìm các chỗ giữ chỗ trong truy vấn và thay bằng giá trị cụ thể. Bao gồm các tham số
[YourCompanyCode],[StartDate]và[EndDate]. Bạn cũng cần thay các ID nhiệm vụ workflow giữ chỗ ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) bằng các giá trị đã xác định ở bước trước. - Chạy truy vấn trích xuất: Chạy truy vấn SQL đã chỉnh sửa trên cơ sở dữ liệu SAP S/4HANA. Tùy khoảng ngày và khối lượng dữ liệu, truy vấn có thể mất nhiều thời gian. Nên chạy vào giờ thấp điểm.
- Kiểm tra kết quả ban đầu: Khi truy vấn chạy xong, xem vài dòng đầu để đảm bảo các cột như JournalEntryId, ActivityName và EventTime có dữ liệu như mong đợi. Tập kết quả cần có một dòng cho mỗi sự kiện nghiệp vụ riêng biệt trong vòng đời bút toán nhật ký.
- Xuất dữ liệu sang CSV: Xuất toàn bộ tập kết quả từ công cụ SQL thành một tệp CSV. Đảm bảo tệp dùng mã hóa UTF-8 để tránh lỗi với ký tự đặc biệt.
- Chuẩn bị tải lên: Trước khi tải lên công cụ process mining, hãy xác nhận tệp CSV có đủ tiêu đề bắt buộc. Dữ liệu đã có cấu trúc nhật ký sự kiện nên thường không cần chuyển đổi hoặc xoay dữ liệu thêm.
Cấu hình
- Core Data Services (CDS) View: Việc trích xuất chủ yếu dùng
I_JournalEntrycho dữ liệu tiêu đề vàI_JournalEntryItemcho thông tin chi tiết về dòng và số tiền. Các view này cung cấp giao diện đơn giản, giàu ngữ nghĩa để truy cập sổ nhật ký chung (ACDOCA). - Bảng hỗ trợ: Để có bức tranh quy trình đầy đủ, truy vấn cũng nối một số bảng SAP tiêu chuẩn:
CDHDRvàCDPOSđể theo dõi thay đổi tài liệu.SRGBRELvàSOODđể xác định thời điểm tệp đính kèm được liên kết qua Generic Object Services (GOS).SWW_WI2OBJvàSWWLOGHISTđể trích xuất các sự kiện chính từ workflow phê duyệt.
- Lọc theo khoảng ngày: Cần lọc dữ liệu theo khoảng ngày cụ thể để kiểm soát hiệu suất. Dùng trường
I_JournalEntry.CreationDateTimetrong mệnh đềWHERE. Với lần phân tích đầu tiên, nên chọn khoảng từ 3 đến 6 tháng. - Lọc theo tổ chức: Luôn lọc theo
CompanyCodeđể chỉ trích xuất dữ liệu của các pháp nhân liên quan. Truy vấn tất cả mã công ty cùng lúc trong hệ thống lớn có thể mất rất nhiều thời gian. - ID nhiệm vụ workflow: Truy vấn có các chỗ giữ chỗ cho ID nhiệm vụ workflow, chẳng hạn
[Workflow Approved Task ID]. Các ID này khác nhau ở mỗi hệ thống SAP và cần được cấu hình chính xác để trích xuất hoạt động workflow. Nếu thiếu các ID này, dữ liệu về sự kiện gửi, phê duyệt hoặc từ chối sẽ không được ghi nhận. - Điều kiện tiên quyết: Người chạy truy vấn cần có quyền đọc rộng đối với các bảng tài chính, hệ thống và workflow. Đây không phải quyền mặc định, cần được cấp riêng.
Truy vấn mẫu sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Các bước
- Xác nhận rằng bạn được phép truy cập SQL trực tiếp vào cơ sở dữ liệu SAP HANA và tài khoản trích xuất có quyền đọc BKPF, ACDOCA cùng mọi nguồn workflow, tệp đính kèm, lịch sử thay đổi, thanh toán bù trừ hoặc đảo ngược được cấu hình cho hệ thống. Thông thường, bạn truy cập cơ sở dữ liệu bằng SAP HANA Database Explorer, SAP HANA Studio hoặc ứng dụng SQL được phê duyệt. Không chạy truy vấn trích xuất trong giao dịch của ứng dụng SAP, trừ khi hệ thống hỗ trợ rõ ràng cách truy cập đó.
- Xác nhận cấu trúc vật lý của BKPF và ACDOCA, gồm trường client, mã công ty, năm tài chính, số chứng từ, loại chứng từ, ngày hạch toán, ngày tạo, giờ tạo, người dùng, số tiền theo nội tệ và các trường đảo ngược hoặc thanh toán bù trừ. Cấu trúc và trường có sẵn có thể khác nhau giữa các hệ thống SAP S/4HANA. Vì vậy, hãy thay các chỗ giữ chỗ trong ngoặc vuông trong truy vấn bằng trường đã xác minh trong hệ thống của bạn.
- Xác định nguồn dữ liệu đáng tin cậy cho sự kiện workflow và tệp đính kèm. BKPF và ACDOCA cung cấp dữ liệu chứng từ kế toán và dòng hạch toán, nhưng không thể tự ghi nhận đầy đủ mọi sự kiện lưu nháp, gửi, từ chối, chỉnh sửa, phê duyệt hoặc đính kèm. Thay các chỗ giữ chỗ cho nguồn workflow và tệp đính kèm bằng view hoặc bảng được phê duyệt trong hệ thống của bạn. Nếu không có nguồn dữ liệu, đừng tự tạo sự kiện. Hãy cấu hình nguồn tương ứng hoặc loại hoạt động đó sau khi được phê duyệt và ghi lại quyết định.
- Thiết lập tham số trích xuất cho khoảng thời gian, mã công ty, loại chứng từ và client cần lấy. Nên bắt đầu xác thực với khoảng từ ba đến sáu tháng. Dùng khoảng thời gian của dấu thời gian sự kiện cho hoạt động vận hành và khoảng ngày hạch toán cho sự kiện kế toán, theo phạm vi quy trình đã thống nhất.
- Chạy toàn bộ truy vấn SQL trong ứng dụng HANA SQL được phê duyệt. Truy vấn tạo một dòng sự kiện cho mỗi hoạt động được trích xuất rõ ràng. Truy vấn dùng BKPF và ACDOCA cho sự kiện kế toán, cùng các view nguồn đã cấu hình cho sự kiện workflow, tệp đính kèm, thay đổi, thanh toán bù trừ và đảo ngược. Truy vấn không suy đoán hoạt động chỉ dựa trên việc chứng từ tồn tại.
- Kiểm tra cấu trúc kết quả. JournalEntryId là mã định danh trường hợp, ActivityName là tên hoạt động, EventTime là dấu thời gian sự kiện. Các thuộc tính nghiệp vụ được đề xuất sẽ có trong kết quả nếu nguồn dữ liệu cung cấp. Xác nhận EventTime có kiểu dấu thời gian và mọi dòng đều có JournalEntryId, ActivityName không rỗng.
- Đối chiếu số lượng chứng từ kế toán bằng cách so sánh các giá trị JournalEntryId riêng biệt với số lượng BKPF dự kiến cho client, mã công ty, năm tài chính và khoảng thời gian đã chọn. Đối chiếu riêng số lượng workflow và tệp đính kèm vì thời hạn lưu trữ và quy tắc dấu thời gian có thể khác dữ liệu kế toán.
- Xác thực thứ tự sự kiện và cách xử lý bản ghi trùng. Nhiều dòng trong ACDOCA không được tạo bản sao sự kiện kế toán, trừ khi thiết kế quy trình yêu cầu sự kiện ở cấp dòng. Dùng logic tổng hợp trong truy vấn để tạo một sự kiện kế toán cho mỗi bút toán nhật ký và loại sự kiện, đồng thời giữ lại ID sự kiện nguồn đã cấu hình nếu có.
- Xuất kết quả thành CSV UTF-8 hoặc định dạng bảng khác được ProcessMind hỗ trợ. Giữ nguyên tên cột JournalEntryId, ActivityName và EventTime. Sắp xếp tệp theo JournalEntryId và EventTime, đồng thời giữ các thuộc tính bổ sung dưới dạng cột. Tải tệp lên ProcessMind và đặt JournalEntryId làm mã định danh trường hợp, ActivityName làm hoạt động, EventTime làm dấu thời gian sự kiện.
Cấu hình
- Khoảng thời gian: Bắt đầu với ba đến sáu tháng. Dùng khoảng ngắn hơn để kiểm tra hiệu năng, chỉ mở rộng sau khi đã xác thực số dòng và mức độ bao phủ sự kiện.
- Phạm vi client và công ty: Thiết lập [Client parameter] và giới hạn CompanyCode ở các pháp nhân cần thiết. Không bỏ điều kiện lọc client trong hệ thống có nhiều client.
- Phạm vi kế toán: Cấu hình [Document type filter] và, nếu phù hợp, bộ lọc năm tài chính và ngày hạch toán. Chỉ đưa cả chứng từ đã hạch toán và chưa hạch toán vào khi nguồn dữ liệu được chọn ghi nhận chúng một cách đáng tin cậy.
- Phạm vi workflow: Cấu hình [Workflow event source] và ánh xạ loại sự kiện cho các hoạt động gửi, từ chối, chỉnh sửa và phê duyệt. Xác nhận dấu thời gian thể hiện lúc tạo, thực hiện hay hoàn tất thao tác workflow.
- Phạm vi tệp đính kèm: Cấu hình [Attachment event source] và trường liên kết tệp đính kèm với bút toán nhật ký. Xác nhận nguồn ghi nhận việc tạo, thay thế hay xóa tệp đính kèm.
- Phạm vi thay đổi: Cấu hình [Change history source] để lấy thay đổi sau khi hạch toán. Xác nhận nguồn nhận diện được bút toán nhật ký và cung cấp dấu thời gian thay đổi đáng tin cậy.
- Phạm vi thanh toán bù trừ: Cấu hình [Clearing source] và mối liên hệ giữa chứng từ kế toán được thanh toán bù trừ với chứng từ thanh toán bù trừ. Quyết định gán sự kiện cho bút toán nhật ký ban đầu, chứng từ thanh toán bù trừ hay cả hai.
- Phạm vi đảo ngược: Cấu hình [Reversal source] và mối liên hệ giữa chứng từ ban đầu với chứng từ đảo ngược. Khi có thông tin liên kết, truy vấn gán hoạt động đảo ngược cho JournalEntryId ban đầu.
- Phân loại hạch toán thủ công: Cấu hình [Manual posting source] hoặc trường nguồn gốc hạch toán đã xác minh. Manual Posting Identified là sự kiện phân loại, nên cần dùng nhất quán dấu thời gian hạch toán hoặc một dấu thời gian khác đã được phê duyệt.
- Số tiền theo tiền tệ: ACDOCA lưu dữ liệu ở cấp dòng. Truy vấn tổng hợp số tiền theo nội tệ cho từng bút toán nhật ký. Xác nhận quy ước dấu và việc có đưa các dòng thống kê, dòng riêng theo sổ cái hoặc sổ cái mở rộng vào hay không.
- Hiệu năng: Chỉ chọn các cột cần thiết, lọc dữ liệu sớm, tránh quét toàn bộ ACDOCA và chạy trong khung giờ báo cáo được phê duyệt. Nếu hệ thống hỗ trợ, hãy dùng điều kiện lọc client, năm tài chính, mã công ty và ngày hạch toán để giới hạn phân vùng cần đọc.
- Xử lý bản ghi trùng: Dùng ID sự kiện nguồn nếu có. Nếu nguồn chứa bản ghi kỹ thuật lặp lại, hãy áp dụng quy tắc loại trùng đã ghi nhận mà không gộp các thao tác workflow riêng biệt.
- Điều kiện tiên quyết: Cần có quyền truy cập cơ sở dữ liệu, kết nối SAP HANA được phê duyệt, quyền truy cập các nguồn workflow và tệp đính kèm đã cấu hình, cấu hình SAP Financial Accounting và workflow phù hợp, cùng định dạng xuất được ProcessMind hỗ trợ.
Truy vấn mẫu sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Các bước
- Tạo chương trình ABAP: Mở ABAP Editor bằng mã giao dịch
SE38. Nhập tên cho chương trình mới, ví dụZ_PM_JE_EXTRACT, rồi nhấp vào 'Create'. Đặt tiêu đề phù hợp, chọn 'Executable Program' trong mục 'Type' và lưu dưới dạng đối tượng cục bộ hoặc trong một package. - Tạo màn hình chọn dữ liệu: Trong chương trình, khai báo các tham số và tùy chọn chọn dữ liệu để người dùng lọc thông tin. Bao gồm khoảng ngày tạo bút toán nhật ký (
P_CPUDT_FR,P_CPUDT_TO), tùy chọn chọn Company Code (SO_BUKRS) và đường dẫn tệp đầu ra trên máy chủ ứng dụng (P_FPATH). - Khai báo cấu trúc dữ liệu: Định nghĩa cấu trúc bảng nội bộ khớp với định dạng nhật ký sự kiện cần dùng. Cấu trúc này lưu kết quả cuối cùng. Đồng thời khai báo các bảng nội bộ và vùng làm việc cho những bảng SAP cần truy vấn, chẳng hạn BKPF, ACDOCA, CDHDR, CDPOS và các bảng workflow liên quan.
- Viết logic chọn dữ liệu: Viết logic ABAP chính để lấy dữ liệu cho 12 hoạt động bắt buộc. Tạo các chương trình con riêng (FORM) cho từng hoạt động để mã dễ quản lý. Ví dụ: tạo FORM cho
get_created_events,get_parked_events,get_workflow_events. - Chọn sự kiện 'Created' và 'Posted': Đọc bảng BKPF theo tiêu chí trên màn hình chọn dữ liệu. Bản ghi trong BKPF thể hiện việc tạo chứng từ. Chứng từ có trạng thái
BSTAT = ' 'được xem là đã hạch toán. Dùng dấu thời gian tạo (CPUDT,CPUTM) làm thời điểm sự kiện. - Chọn sự kiện 'Parked': Đọc bảng VBKPF, nơi lưu tiêu đề chứng từ chờ hạch toán. Dấu thời gian tạo trong bảng này thể hiện thời điểm chứng từ được lưu chờ.
- Chọn sự kiện 'Workflow' (Submitted, Approved, Rejected): Truy vấn các bảng workflow như SWW_WI2OBJ (để liên kết đối tượng bút toán nhật ký với phiên bản workflow) và SWWLOGHIST hoặc SWWIHEAD (để lấy chi tiết và thời gian của từng bước). Bạn cần xác định ID tác vụ workflow cụ thể dùng cho thao tác gửi, phê duyệt và từ chối trong hệ thống.
- Chọn sự kiện 'Change' và 'Correction': Truy vấn các bảng tài liệu thay đổi CDHDR (tiêu đề) và CDPOS (mục) với
OBJECTCLAS = 'BELEG'. Với 'Changed After Posting', lọc các thay đổi có dấu thời gian sau ngày hạch toán chứng từ. Với 'Corrected', lọc các thay đổi đối với chứng từ đang chờ hạch toán hoặc bị từ chối. - Chọn sự kiện 'Reversal' và 'Cleared': Tìm chứng từ đảo ngược bằng cách kiểm tra trường
STBLG(số chứng từ bị đảo ngược) trong BKPF. Thời điểm đảo ngược là thời điểm tạo chứng từ đảo ngược. Tìm sự kiện thanh toán bù trừ bằng cách lấy ngày thanh toán bù trừ mới nhất (AUGDT) từ bảng ACDOCA cho các dòng của một bút toán nhật ký. - Gộp và sắp xếp dữ liệu: Khi lấy dữ liệu của từng hoạt động, thêm kết quả vào bảng nội bộ chính. Sau khi hoàn tất, sắp xếp bảng theo
JournalEntryIdvàEventTimeđể các sự kiện của từng trường hợp theo đúng thứ tự thời gian. - Tạo tệp đầu ra: Dùng các câu lệnh
OPEN DATASET,LOOP AT... TRANSFERvàCLOSE DATASETđể ghi nội dung bảng nội bộ cuối cùng đã sắp xếp vào đường dẫn tệp được chỉ định trên máy chủ ứng dụng SAP. Tệp cần ở định dạng CSV và có dòng tiêu đề. - Lên lịch chạy: Để trích xuất định kỳ, dùng mã giao dịch
SM36tạo một background job chạy chương trìnhZ_PM_JE_EXTRACTtheo lịch, chẳng hạn hàng tuần hoặc hàng tháng. Cách này giúp tự động xuất dữ liệu.
Cấu hình
- Khoảng ngày: Màn hình chọn dữ liệu cần có khoảng ngày bắt buộc cho ngày tạo bút toán nhật ký (
CPUDT). Nên trích xuất theo từng đợt vừa phải, chẳng hạn 3-6 tháng mỗi lần, để đảm bảo hiệu năng. - Company Code (
BUKRS): Đây là bộ lọc quan trọng để chỉ trích xuất dữ liệu của các pháp nhân liên quan đến phân tích process mining. Không nên trích xuất tất cả mã công ty cùng lúc. - Loại chứng từ (
BLART): Bạn có thể thêm bộ lọc tùy chọn này để tập trung vào một số loại bút toán nhật ký, chẳng hạn 'SA' cho hạch toán tài khoản sổ cái hoặc 'KR' cho hóa đơn nhà cung cấp. Bộ lọc giúp giảm lượng dữ liệu và tăng mức độ phù hợp của tập dữ liệu. - Đường dẫn tệp: Chương trình cần một đường dẫn logic trên máy chủ ứng dụng SAP để ghi tệp đầu ra. Đảm bảo đường dẫn hợp lệ và tài khoản hệ thống SAP có quyền ghi vào thư mục đó. Dùng giao dịch
AL11để quản lý và xem thư mục trên máy chủ. - ID tác vụ workflow: Cần cấu hình logic trích xuất sự kiện workflow (Submitted, Approved, Rejected) bằng ID tác vụ cụ thể trong quy trình phê duyệt bút toán nhật ký của tổ chức. Các ID này thường được tùy chỉnh, cần nhờ chuyên gia tư vấn hoặc nhà phát triển workflow xác định.
- Điều kiện tiên quyết: Tài khoản người dùng hoặc hệ thống chạy chương trình cần quyền phát triển để tạo và chạy chương trình ABAP (
S_DEVELOP), cùng quyền đọc rộng đối với các bảng tài chính (BKPF, ACDOCA), bảng nhật ký thay đổi (CDHDR, CDPOS) và bảng workflow (SWW*).
Truy vấn mẫu abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Sẵn sàng bắt đầu?
Dùng mẫu này để chuẩn bị dữ liệu và tìm ra những thông tin quan trọng về quy trình ghi nhận đến báo cáo, bút toán nhật ký. Bắt đầu cải tiến quy trình ngay hôm nay.
Tối ưu hóa bút toán nhật ký trong quy trình ghi nhận đến báo cáo
Cải tiến quy trình và giảm 30% thời gian xử lý bút toán nhật ký trong quy trình ghi nhận đến báo cáo.
Không cần thẻ tín dụng. Thiết lập chỉ trong vài phút.