Mẫu dữ liệu Order to Cash - Lập hóa đơn và thanh toán
Mẫu dữ liệu Order to Cash - Lập hóa đơn và thanh toán
- Các thuộc tính nên có để phân tích đầy đủ
- Các bước và mốc chính cần theo dõi trong quy trình
- Hướng dẫn thực tế để trích xuất dữ liệu từ SAP ECC
Thuộc tính Order to Cash - Lập hóa đơn và thanh toán
| Tên | Mô tả | ||
|---|---|---|---|
| Hoạt động ActivityName | Tên sự kiện hoặc bước nghiệp vụ diễn ra trong vòng đời hóa đơn. | ||
| Mô tả Thuộc tính này mô tả một hành động cụ thể hoặc thay đổi trạng thái trong quy trình thanh toán, chẳng hạn như 'Đã tạo hóa đơn', 'Đã hạch toán hóa đơn' hoặc 'Đã nhận khoản thanh toán từ khách hàng'. Các hoạt động này được xác định từ nhiều sự kiện hệ thống, thay đổi trạng thái chứng từ hoặc mã giao dịch cụ thể do người dùng thực hiện. Chuỗi hoạt động tạo thành luồng quy trình, làm nền tảng cho phân tích process mining. Khi xem xét các hoạt động, tổ chức có thể biết những bước nào đã diễn ra, theo thứ tự nào và với tần suất ra sao. Từ đó, bạn có thể so sánh cách quy trình thực sự vận hành với quy trình đã thiết kế. Vì sao điều này quan trọng Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp trực quan hóa và phân tích luồng quy trình, các sai lệch và điểm nghẽn. Lấy dữ liệu ở đâu Đây là thuộc tính khái niệm được suy ra từ nhiều nguồn, chẳng hạn như mã giao dịch (CDHDR-TCODE), thay đổi trạng thái chứng từ (VBUK-FKSTK) và bút toán chứng từ kế toán. Ví dụ Đã tạo hóa đơnHóa đơn đã ghi sổĐã gửi nhắc thanh toánHóa đơn đã tất toán | |||
| Số hóa đơn InvoiceNumber | Mã định danh duy nhất của chứng từ thanh toán, dùng làm mã hồ sơ chính cho quy trình lập hóa đơn. | ||
| Mô tả Số hóa đơn, được gọi là Số chứng từ thanh toán trong SAP, là mã định danh duy nhất cho từng hóa đơn. Trong process mining, mã này đóng vai trò CaseId, nhóm mọi hoạt động liên quan như tạo, hạch toán, gửi, thanh toán và tất toán thành một trường hợp quy trình xuyên suốt. Phân tích quy trình theo Số hóa đơn giúp bạn theo dõi đầy đủ vòng đời của từng giao dịch thanh toán, từ lúc bắt đầu đến khi tất toán. Đây là cơ sở quan trọng để tính các KPI như Số ngày thu tiền bình quân (DSO) và tổng thời gian xử lý hóa đơn, từ đó đo lường và cải thiện hiệu quả. Vì sao điều này quan trọng Đây là khóa thiết yếu để theo dõi toàn bộ hành trình của hóa đơn, giúp phân tích thời gian xử lý, điểm nghẽn và các khác biệt trong từng giao dịch thanh toán. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: VBELN Ví dụ 90001234900012359000123690001237 | |||
| Thời gian bắt đầu EventTime | Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện cụ thể diễn ra. | ||
| Mô tả Thời gian sự kiện ghi lại chính xác ngày giờ của từng hoạt động trong vòng đời hóa đơn. Đây là dữ liệu nền tảng cho mọi phân tích theo thời gian trong process mining, bao gồm tính thời gian xử lý, xác định điểm nghẽn và theo dõi hiệu quả quy trình so với thỏa thuận mức dịch vụ. Thuộc tính này thường được tạo bằng cách kết hợp trường ngày, chẳng hạn Ngày hạch toán (BUDAT), với trường giờ (UZEIT) từ các bảng SAP ghi nhận thay đổi hoặc thời điểm tạo chứng từ. Dấu thời gian chính xác giúp xây dựng nhật ký sự kiện đáng tin cậy và đảm bảo kết quả phân tích hiệu quả có giá trị. Vì sao điều này quan trọng Thuộc tính này là nền tảng cho mọi phân tích hiệu quả, giúp tính thời gian xử lý, thời lượng và thời gian chờ giữa các bước trong quy trình. Lấy dữ liệu ở đâu Được tạo từ nhiều trường ngày và giờ trong các bảng, chẳng hạn BKPF (BUDAT, CPUTM), VBRK (ERDAT, ERZET) và các bảng nhật ký thay đổi như CDHDR (UDATE, UTIME). Ví dụ 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Loại chứng từ thanh toán BillingDocumentType | Mã phân loại chứng từ thanh toán, chẳng hạn hóa đơn, giấy báo có hoặc giấy báo nợ. | ||
| Mô tả Loại chứng từ thanh toán phân loại giao dịch theo mục đích nghiệp vụ. Ví dụ, 'F2' là hóa đơn khách hàng tiêu chuẩn, còn 'G2' là giấy báo có. SAP được cấu hình để xử lý từng loại chứng từ thanh toán theo cách phù hợp. Trong process mining, thuộc tính này rất cần thiết để lọc và so sánh các tình huống thanh toán khác nhau. Chuyên viên phân tích có thể xem riêng quy trình hóa đơn tiêu chuẩn và giấy báo có để hiểu luồng, thời gian xử lý và khó khăn đặc thù của từng loại, từ đó cải tiến quy trình có trọng tâm hơn. Vì sao điều này quan trọng Giúp phân nhóm và phân tích các quy trình thanh toán khác nhau, chẳng hạn hóa đơn tiêu chuẩn và giấy báo có, vốn thường có luồng xử lý rất khác nhau. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: FKART Ví dụ F2G2L2IV | |||
| Mã công ty CompanyCode | Mã định danh pháp nhân đã phát hành hóa đơn. | ||
| Mô tả Mã công ty đại diện cho một đơn vị kế toán và pháp lý độc lập trong SAP. Mọi giao dịch tài chính, bao gồm hóa đơn, đều được hạch toán vào một mã công ty cụ thể. Đây là thành phần dữ liệu tổ chức cơ bản. Trong process mining, mã công ty được dùng để phân tích và so sánh hiệu quả quy trình thanh toán giữa các pháp nhân trong cùng tập đoàn. Nhờ đó, doanh nghiệp có thể tìm ra cách làm hiệu quả ở một đơn vị để áp dụng cho các đơn vị khác, đồng thời đảm bảo phân tích phù hợp với cơ cấu tổ chức. Vì sao điều này quan trọng Giúp lọc và so sánh quy trình giữa các pháp nhân, phục vụ phân tích tài chính và đối chiếu hiệu quả giữa các đơn vị. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: BUKRS Ví dụ 10002000US01DE01 | |||
| Mã khách hàng CustomerNumber | Mã duy nhất xác định khách hàng nhận hóa đơn. | ||
| Mô tả Mã khách hàng liên kết hóa đơn với một khách hàng hoặc đối tác kinh doanh cụ thể. Thuộc tính này rất quan trọng để phân nhóm và phân tích quy trình thanh toán theo đặc điểm khách hàng. Chuyên viên phân tích có thể dùng trường này để so sánh Số ngày thu tiền bình quân (DSO) giữa các khách hàng, xác định khách hàng thường thanh toán trễ hoặc phân tích mức độ tuân thủ điều khoản thanh toán. Hiểu rõ các xu hướng này giúp doanh nghiệp quản lý quan hệ khách hàng và xây dựng cách thu hồi công nợ phù hợp với từng nhóm. Vì sao điều này quan trọng Hỗ trợ phân tích theo từng khách hàng, giúp nhận diện thói quen thanh toán, đánh giá DSO theo khách hàng và điều chỉnh cách thu hồi công nợ. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: KUNRG (Bên thanh toán) hoặc KUNAG (Bên mua hàng). Ví dụ 100023200541CUST-A487910345 | |||
| Tên người dùng UserName | ID của người dùng thực hiện hoạt động hoặc tạo chứng từ. | ||
| Mô tả Thuộc tính này ghi nhận ID người dùng SAP chịu trách nhiệm cho một sự kiện, chẳng hạn như tạo hóa đơn hoặc hạch toán khoản thanh toán. Đây là dữ liệu cần thiết để phân tích vai trò của con người trong quy trình. Dữ liệu này giúp tìm hiểu sự khác biệt về hiệu quả giữa người dùng hoặc nhóm, xác định nhu cầu đào tạo và phát hiện nguy cơ không tuân thủ. Thuộc tính cũng giúp phân biệt hoạt động thủ công do người dùng thực hiện với các bước tự động do tài khoản hệ thống hoặc tài khoản chạy theo lô thực hiện, từ đó tính tỷ lệ tự động hóa. Vì sao điều này quan trọng Hỗ trợ phân tích hiệu quả của người dùng và phân bổ khối lượng công việc, đồng thời phân biệt hoạt động thủ công với hoạt động tự động để thúc đẩy tự động hóa và nâng cao hiệu quả. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: ERNAM (Người tạo) hoặc BKPF, Trường: USNAM (Tên người dùng) hoặc CDHDR, Trường: USERNAME (Người dùng). Ví dụ JSMITHBW_BATCHLROSSIMKUMAR | |||
| Tổng giá trị hóa đơn TotalInvoiceAmount | Tổng giá trị thuần của chứng từ thanh toán. | ||
| Mô tả Thuộc tính này thể hiện tổng giá trị thuần của hóa đơn, chưa bao gồm thuế. Giá trị hóa đơn là dữ liệu tài chính quan trọng gắn với quy trình thanh toán. Bạn có thể dùng thuộc tính này để phân nhóm hóa đơn giá trị cao và thấp, rồi so sánh luồng xử lý của chúng. Thuộc tính cũng giúp ưu tiên thu hồi công nợ hoặc tìm hiểu vì sao hóa đơn giá trị cao mất nhiều thời gian hơn để được phê duyệt hoặc thanh toán. Nhờ đó, phân tích quy trình có thêm bối cảnh tài chính cần thiết. Vì sao điều này quan trọng Cung cấp bối cảnh tài chính cần thiết để phân tích theo giá trị hóa đơn, chẳng hạn xác định hóa đơn giá trị cao có quy trình khác hoặc mất nhiều thời gian hơn để tất toán hay không. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: NETWR Ví dụ 1500.7525000.00500.0012345.67 | |||
| Có làm lại IsRework | Cờ cho biết hoạt động có phải là bước làm lại hoặc điều chỉnh hay không. | ||
| Mô tả Thuộc tính được tính toán này xác định các hoạt động thể hiện việc làm lại, chẳng hạn như 'Đã điều chỉnh hóa đơn' hoặc đảo chứng từ. Thông thường, đây là cờ boolean được suy ra từ tên hoạt động hoặc mã giao dịch liên quan đến việc điều chỉnh và hủy, chẳng hạn 'VF11' để hủy chứng từ thanh toán. Trong process mining, cờ này rất hữu ích để định lượng khối lượng công việc phải làm lại trong quy trình thanh toán. Cờ hỗ trợ trực tiếp các KPI như Tỷ lệ điều chỉnh hóa đơn và giúp trực quan hóa các vòng lặp làm lại trên sơ đồ quy trình, qua đó làm rõ những điểm kém hiệu quả và vấn đề chất lượng khiến chi phí vận hành tăng và thanh toán chậm trễ. Vì sao điều này quan trọng Giúp định lượng điểm kém hiệu quả và vấn đề chất lượng trong quy trình bằng cách cho thấy công sức dành cho việc sửa lỗi, đồng thời hỗ trợ trực tiếp các KPI về làm lại. Lấy dữ liệu ở đâu Được suy ra từ Tên hoạt động hoặc Mã giao dịch. Ví dụ: IF ActivityName = 'Invoice Corrected' OR TransactionCode = 'VF11' THEN true ELSE false. Ví dụ truefalse | |||
| Có tự động hóa IsAutomated | Cờ cho biết hoạt động do người dùng hệ thống thực hiện hay được tự động hóa. | ||
| Mô tả Thuộc tính được tính toán này là cờ boolean dùng để phân biệt hoạt động thủ công và tự động. Thông thường, thuộc tính được xác định bằng cách đối chiếu Tên người dùng với danh sách ID tài khoản hệ thống hoặc tài khoản chạy theo lô, chẳng hạn 'BATCHUSER' hoặc 'SAPSYSTEM'. Cờ này rất cần thiết để đo lường mức độ tự động hóa trong quy trình thanh toán, mục tiêu quan trọng của nhiều tổ chức muốn nâng cao hiệu quả và giảm chi phí. KPI Tỷ lệ thanh toán tự động được tính trực tiếp từ thuộc tính này, giúp theo dõi tiến độ của các sáng kiến tự động hóa. Vì sao điều này quan trọng Hỗ trợ trực tiếp việc tính tỷ lệ thanh toán tự động, giúp đo lường hiệu quả quy trình và theo dõi tác động của các dự án tự động hóa. Lấy dữ liệu ở đâu Được suy ra từ thuộc tính Tên người dùng. Logic có thể như sau: IF UserName IN ('BATCH', 'SYSTEM', 'RFCUSER') THEN true ELSE false. Ví dụ truefalse | |||
| Điều khoản thanh toán PaymentTerms | Các điều kiện người bán đặt ra để hoàn tất giao dịch, bao gồm lịch thanh toán. | ||
| Mô tả Điều khoản thanh toán quy định thời điểm đến hạn, chẳng hạn 'Net 30' hoặc 'Net 60'. Các điều khoản này được thỏa thuận với khách hàng và ảnh hưởng trực tiếp đến dòng tiền. Phân tích quy trình theo điều khoản thanh toán có thể cho thấy điều khoản nào gắn với chu kỳ thanh toán dài hơn hoặc tỷ lệ thanh toán trễ cao hơn. Thông tin này giúp doanh nghiệp đàm phán điều khoản tốt hơn với khách hàng hoặc điều chỉnh kế hoạch tài chính. Đây cũng là dữ liệu đầu vào quan trọng để tính ngày đến hạn thanh toán hóa đơn. Vì sao điều này quan trọng Giúp phân tích thói quen thanh toán của khách hàng và tác động đến dòng tiền theo các điều khoản đã thỏa thuận, từ đó hỗ trợ tối ưu hóa thỏa thuận thương mại. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: ZTERM Ví dụ Z030Z060Z001 | |||
| Đơn vị kinh doanh bán hàng SalesOrganization | Đơn vị tổ chức chịu trách nhiệm bán sản phẩm hoặc dịch vụ. | ||
| Mô tả Đơn vị kinh doanh bán hàng là một đơn vị tổ chức trong SAP, chịu trách nhiệm phân phối hàng hóa và dịch vụ, đồng thời đàm phán các điều kiện bán hàng. Đây là trường quan trọng để tổ chức hoạt động bán hàng và phân phối. Trong process mining, thuộc tính này giúp phân tích quy trình thanh toán theo cơ cấu bán hàng. Bạn có thể so sánh hiệu quả giữa các đơn vị kinh doanh bán hàng để xác định khu vực hoặc ngành hàng nào xử lý thanh toán hiệu quả hơn, đồng thời hỗ trợ áp dụng các cách làm tốt trên diện rộng. Vì sao điều này quan trọng Hỗ trợ so sánh hiệu quả giữa các bộ phận bán hàng hoặc khu vực, giúp tìm ra cách làm tốt và những điểm cần cải thiện. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: VKORG Ví dụ 1000NA01EU01AP01 | |||
| Hệ thống nguồn SourceSystem | Xác định hệ thống nguồn nơi dữ liệu được trích xuất. | ||
| Mô tả Thuộc tính này xác định hệ thống lưu trữ dữ liệu gốc. Trong doanh nghiệp có nhiều hệ thống ERP hoặc hệ thống tích hợp, trường này giúp phân biệt dữ liệu từ các nguồn khác nhau. Với process mining, thuộc tính này cần thiết để xác thực dữ liệu và so sánh quy trình giữa các hệ thống hoặc đơn vị trong tổ chức. Trường này thường được điền bằng một giá trị cố định trong quá trình trích xuất dữ liệu để gắn nhãn cho tập dữ liệu. Vì sao điều này quan trọng Cho biết nguồn gốc dữ liệu. Đây là thông tin quan trọng trong môi trường có nhiều hệ thống, giúp đảm bảo tính toàn vẹn dữ liệu và hỗ trợ phân tích theo từng hệ thống. Lấy dữ liệu ở đâu Đây thường là giá trị cố định được thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL), dùng để xác định phiên bản SAP ECC cụ thể, chẳng hạn 'ECC_PROD_NA'. Ví dụ SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian của lần làm mới hoặc trích xuất dữ liệu gần nhất từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này cho biết lần gần nhất tập dữ liệu được cập nhật từ hệ thống nguồn. Đây là thông tin cần thiết để người dùng biết dữ liệu đang xem mới đến đâu. Trên dashboard và báo cáo, dấu thời gian này cho biết dữ liệu có kịp thời hay không, đồng thời giúp các bên liên quan hiểu rằng những giao dịch vừa phát sinh có thể chưa xuất hiện. Giá trị này thường được tạo khi kết thúc quá trình trích xuất dữ liệu. Vì sao điều này quan trọng Cho người dùng biết dữ liệu được cập nhật đến thời điểm nào, yếu tố quan trọng khi đưa ra quyết định vận hành dựa trên kết quả phân tích. Lấy dữ liệu ở đâu Được tạo và lưu trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL). Ví dụ 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Mã giao dịch TransactionCode | Mã giao dịch SAP dùng để thực hiện một hoạt động. | ||
| Mô tả Mã giao dịch, hay T-Code, là mã định danh duy nhất cho một chức năng hoặc chương trình cụ thể trong SAP, chẳng hạn 'VF01' để tạo chứng từ thanh toán. Ghi nhận T-Code cho từng sự kiện giúp xem quy trình được thực hiện như thế nào ở cấp độ kỹ thuật của hệ thống. Thông tin này rất hữu ích khi phân tích nguyên nhân gốc rễ. Ví dụ, nếu lỗi thường xuyên xảy ra, chuyên viên phân tích có thể kiểm tra xem người dùng có đang dùng mã giao dịch không theo chuẩn hay không. T-Code cũng giúp xác định tên hoạt động và hiểu những chức năng hệ thống nào được sử dụng trong quy trình. Vì sao điều này quan trọng Cung cấp thông tin kỹ thuật về cách một hoạt động được thực hiện, giúp phân tích nguyên nhân gốc rễ của sai lệch quy trình và xác định các thao tác không theo chuẩn của người dùng. Lấy dữ liệu ở đâu Bảng SAP ECC: CDHDR, Trường: TCODE Ví dụ VF01VF02FB01F-28 | |||
| Ngày chứng từ DocumentDate | Ngày ghi trên chứng từ gốc do nhà cung cấp hoặc người tạo cung cấp. | ||
| Mô tả Ngày chứng từ là ngày phát hành chứng từ gốc. Trong quy trình thanh toán, đây thường là ngày tạo hóa đơn và thường được dùng làm căn cứ tính ngày đến hạn thanh toán. Ngày này rất quan trọng đối với báo cáo tài chính và tính các chỉ số như Số ngày thu tiền bình quân (DSO). Với khách hàng, đây là mốc bắt đầu thời gian thu hồi công nợ. Phân tích chênh lệch giữa ngày chứng từ và ngày hạch toán có thể cho thấy sự chậm trễ nội bộ trong quá trình xử lý chứng từ thanh toán. Vì sao điều này quan trọng Làm mốc để tính tuổi hóa đơn và DSO, đồng thời cung cấp căn cứ quan trọng cho phân tích tài chính và điều khoản thanh toán. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: FKDAT (Ngày thanh toán) Ví dụ 2023-04-152023-04-162023-05-20 | |||
| Ngày đến hạn thanh toán hóa đơn InvoiceDueDate | Ngày khách hàng dự kiến phải thanh toán. | ||
| Mô tả Ngày đến hạn thanh toán hóa đơn là hạn cuối khách hàng phải thanh toán theo điều khoản thanh toán. Ngày này rất quan trọng để quản lý khoản phải thu và bắt đầu các hoạt động thu hồi công nợ. Thuộc tính này được dùng để tính KPI Tỷ lệ thanh toán đúng hạn bằng cách so sánh với ngày thanh toán thực tế. Phân tích hóa đơn theo ngày đến hạn giúp dự báo dòng tiền và ưu tiên thu hồi các khoản sắp đến hạn hoặc đã quá hạn. Ngày này thường được tính từ ngày cơ sở và điều khoản thanh toán. Vì sao điều này quan trọng Là mốc để đo lường tỷ lệ thanh toán đúng hạn, đồng thời cần thiết cho việc quản lý khoản phải thu và dự báo dòng tiền. Lấy dữ liệu ở đâu Được tính dựa trên ngày cơ sở (BSEG-ZFBDT) và điều khoản thanh toán (BSEG-ZTERM). Giá trị này không phải lúc nào cũng được lưu trong một trường riêng. Ví dụ 2023-05-152023-05-302023-06-20 | |||
| Ngày hạch toán PostingDate | Ngày chứng từ được ghi vào sổ kế toán tài chính. | ||
| Mô tả Ngày hạch toán xác định kỳ tài chính ghi nhận giao dịch trong sổ cái. Đây là mốc quan trọng đối với kế toán và báo cáo tài chính. Khoảng trễ giữa ngày tạo chứng từ và ngày hạch toán có thể cho thấy quy trình xử lý chứng từ thanh toán nội bộ chưa hiệu quả. Trong process mining, ngày hạch toán đánh dấu một mốc quan trọng trong vòng đời hóa đơn. Khoảng thời gian từ lúc tạo hóa đơn đến khi hạch toán có thể là KPI quan trọng để đánh giá hiệu quả của bộ phận thanh toán. Vì sao điều này quan trọng Đánh dấu một mốc tài chính quan trọng và cần thiết cho công tác kế toán. Khoảng thời gian từ lúc tạo hóa đơn đến khi hạch toán là thước đo hiệu quả xử lý nội bộ. Lấy dữ liệu ở đâu Bảng SAP ECC: BKPF, Trường: BUDAT Ví dụ 2023-04-152023-04-172023-05-21 | |||
| Ngày tất toán ClearingDate | Ngày nhận được khoản thanh toán và hóa đơn được tất toán khỏi khoản phải thu. | ||
| Mô tả Ngày tất toán là ngày một khoản mục chưa thanh toán, chẳng hạn hóa đơn, được đánh dấu là đã thanh toán hoặc 'đã tất toán' trong hệ thống tài chính. Ngày này thể hiện thời điểm tiền được xem là đã thu và đối soát xong. Đây là một trong những ngày quan trọng nhất trong chu kỳ Order to Cash. Ngày này là mốc kết thúc để tính Số ngày thu tiền bình quân (DSO) và tổng thời gian từ hóa đơn đến khi thu tiền. Phân tích ngày tất toán giúp đo lường hiệu quả của quy trình thu hồi công nợ. Vì sao điều này quan trọng Đánh dấu bước cuối trong vòng đời hóa đơn, làm mốc kết thúc để tính DSO và tổng thời gian xử lý, đồng thời phản ánh hiệu quả thu tiền. Lấy dữ liệu ở đâu Bảng SAP ECC: BSAD, Trường: AUGDT Ví dụ 2023-05-142023-06-012023-06-25 | |||
| Số chứng từ bán hàng SalesDocumentNumber | Mã định danh đơn hàng bán ban đầu dẫn đến việc phát hành hóa đơn. | ||
| Mô tả Thuộc tính này liên kết trực tiếp hóa đơn với đơn hàng bán khởi tạo giao dịch. Khả năng truy vết này rất quan trọng để phân tích toàn bộ quy trình Order to Cash. Khi kết nối quy trình thanh toán với quy trình đơn hàng bán trước đó, tổ chức có thể phân tích tổng thời gian từ lúc khách hàng đặt hàng đến khi nhận được tiền. Nhờ đó, bạn có thể xác định chậm trễ trong khâu thanh toán bắt nguồn từ bán hàng, thực hiện đơn hàng hay chính bộ phận thanh toán, qua đó có cái nhìn đầy đủ hơn về quy trình. Vì sao điều này quan trọng Liên kết quy trình thanh toán với đơn hàng bán, giúp phân tích toàn bộ quy trình Order to Cash và xác định chậm trễ giữa các bộ phận. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRP, Trường: VGBEL Ví dụ 100000451000004610000047 | |||
| Tiền tệ Currency | Mã tiền tệ áp dụng cho các khoản tiền ghi trên hóa đơn. | ||
| Mô tả Thuộc tính này cho biết tiền tệ của giao dịch, chẳng hạn USD, EUR hoặc JPY. Nhờ đó, bạn có thể hiểu đúng các giá trị tiền tệ như Tổng giá trị hóa đơn. Khi phân tích dữ liệu từ một tổ chức đa quốc gia, trường tiền tệ rất cần thiết để diễn giải và quy đổi chính xác các số liệu tài chính. Trường này hỗ trợ lập báo cáo nhất quán và tránh cộng gộp các khoản tiền khi chưa quy đổi đúng tiền tệ, vốn có thể dẫn đến phân tích tài chính sai lệch. Vì sao điều này quan trọng Cung cấp bối cảnh cần thiết cho mọi giá trị tiền tệ, giúp phân tích tài chính chính xác, nhất là khi có nhiều loại tiền tệ. Lấy dữ liệu ở đâu Bảng SAP ECC: VBRK, Trường: WAERK Ví dụ USDEURGBPJPY | |||
Hoạt động Order to Cash - Lập hóa đơn và thanh toán
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Đã gửi hóa đơn cho khách hàng | Cho biết hóa đơn đã được gửi cho khách hàng qua một kênh đầu ra xác định như bản in, email hoặc EDI. Sự kiện này thường được ghi nhận trong nhật ký hệ thống quản lý đầu ra. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng, bắt đầu tính thời hạn thanh toán của khách hàng. Chậm trễ ở bước này ảnh hưởng trực tiếp đến thời điểm dự kiến nhận tiền và hiệu quả thu hồi công nợ. Lấy dữ liệu ở đâu Có thể suy ra từ ngày và giờ xử lý trong bảng trạng thái thông điệp (NAST) của loại đầu ra tương ứng với hóa đơn. Thu thập Suy ra từ mục trong bảng NAST có trạng thái xử lý '1' (đã xử lý thành công). Loại sự kiện inferred | |||
| Đã nhận thanh toán từ khách hàng | Khách hàng đã thanh toán và khoản tiền được ghi nhận trong hệ thống dưới dạng tiền thu hoặc tiền gửi ngân hàng. Thao tác này tạo một chứng từ thanh toán riêng, chưa được đối chiếu với hóa đơn cụ thể. | ||
| Vì sao điều này quan trọng Đây là một mốc quan trọng trong chu kỳ chuyển đổi tiền mặt. Thời gian từ lúc gửi hóa đơn đến khi nhận thanh toán là một thành phần chính của Days Sales Outstanding (DSO). Lấy dữ liệu ở đâu Được ghi nhận thành chứng từ mới trong BKPF và BSEG, thường có loại chứng từ chỉ khoản thanh toán của khách hàng, chẳng hạn 'DZ'. Ngày ghi sổ (BUDAT) đánh dấu sự kiện này. Thu thập Dựa trên ngày ghi sổ của chứng từ thanh toán khách hàng trong BKPF. Loại sự kiện explicit | |||
| Đã tạo hóa đơn | Đánh dấu thời điểm chứng từ lập hóa đơn được tạo trong hệ thống. Sự kiện này được ghi nhận khi có mục mới được tạo trong bảng tiêu đề chứng từ kế toán (BKPF) với loại chứng từ dành riêng cho hóa đơn. | ||
| Vì sao điều này quan trọng Đây là điểm bắt đầu của toàn bộ quy trình lập hóa đơn. Phân tích thời gian từ sự kiện này giúp đo thời gian tạo hóa đơn và là cơ sở tính Days Sales Outstanding (DSO). Lấy dữ liệu ở đâu Được ghi nhận trong bảng BKPF. Ngày tạo (CPUDT) và giờ tạo (CPUTM) của một số chứng từ cụ thể (BELNR) đánh dấu sự kiện này. Loại chứng từ (BLART) cho biết đây là hóa đơn. Thu thập Dựa trên dấu thời gian tạo (CPUDT) trong bảng BKPF của chứng từ hóa đơn. Loại sự kiện explicit | |||
| Hóa đơn đã ghi sổ | Hóa đơn được ghi nhận chính thức trong sổ phụ các khoản phải thu và sổ cái. Sự kiện này khiến hóa đơn có giá trị ràng buộc pháp lý và thể hiện khoản nợ khách hàng phải trả. | ||
| Vì sao điều này quan trọng Đây là một mốc quan trọng, chính thức bắt đầu tính thời gian thu tiền. Khoảng thời gian từ lúc tạo đến lúc ghi sổ có thể cho thấy chậm trễ trong xử lý nội bộ, ảnh hưởng đến dòng tiền. Lấy dữ liệu ở đâu Được ghi nhận trong bảng BKPF. Ngày ghi sổ (BUDAT) của số chứng từ (BELNR) đánh dấu sự kiện này. Với chứng từ lưu tạm, đây là thời điểm chứng từ được chuyển thành chứng từ đã ghi sổ. Thu thập Dựa trên ngày ghi sổ (BUDAT) trong bảng BKPF của chứng từ hóa đơn. Loại sự kiện explicit | |||
| Hóa đơn đã tất toán | Trạng thái cuối cùng của hóa đơn đã được thanh toán thành công, cho biết khoản mục chưa thanh toán đã được đóng bằng khoản thanh toán hoặc giấy báo có tương ứng. Hóa đơn được xem là đã tất toán đầy đủ. | ||
| Vì sao điều này quan trọng Đánh dấu hoàn tất thành công chu trình Order to Cash của một hóa đơn. Đây là sự kiện kết thúc chính để đo thời gian chu kỳ hóa đơn trung bình. Lấy dữ liệu ở đâu Xảy ra khi các trường chứng từ tất toán (AUGBL) và ngày tất toán (AUGDT) được điền cho mục hàng hóa đơn trong bảng BSEG. Thu thập Sự kiện xảy ra vào ngày tất toán (AUGDT) được ghi trong bảng BSEG cho mục hàng hóa đơn. Loại sự kiện explicit | |||
| Đã đến hạn thanh toán hóa đơn | Sự kiện được tính toán để đánh dấu ngày đến hạn thanh toán hóa đơn theo điều khoản thanh toán. Đây không phải hoạt động do người dùng hoặc hệ thống thực hiện, mà là một mốc thời gian quan trọng. | ||
| Vì sao điều này quan trọng Sự kiện này cần thiết để phân tích hành vi thanh toán và mức độ tuân thủ. Đây là mốc cơ sở để xác định khoản thanh toán đúng hạn hay trễ hạn và tính KPI Tỷ lệ thanh toán đúng hạn. Lấy dữ liệu ở đâu Được xác định bằng cách so sánh ngày hiện tại với ngày đến hạn ròng. Ngày đến hạn nằm trong trường BSEG-ZFBDT hoặc được tính từ ngày cơ sở và điều khoản thanh toán. Thu thập So sánh ngày hệ thống với trường ngày đến hạn ròng trong mục hàng hóa đơn (BSEG). Loại sự kiện calculated | |||
| Đã ghi nhận thanh toán cho hóa đơn | Khoản thanh toán đã nhận từ khách hàng được đối chiếu và ghi nhận cho hóa đơn chưa thanh toán cụ thể, đánh dấu khoản mục chờ tất toán. Đây là bước đối chiếu liên kết khoản thanh toán với khoản nợ. | ||
| Vì sao điều này quan trọng Hoạt động này rất quan trọng để đo thời gian ghi nhận tiền thu. Chậm ghi nhận tiền có thể khiến tình trạng khoản phải thu bị phản ánh sai và che khuất số tiền mặt hiện có. Lấy dữ liệu ở đâu Suy ra từ giao dịch tất toán, chẳng hạn F-32, giao dịch này điền các trường tất toán trong mục hàng hóa đơn. Dấu thời gian sự kiện là ngày tất toán. Thu thập Suy ra khi trường ngày tất toán (AUGDT) được điền trong bảng mục hàng hóa đơn (BSEG). Loại sự kiện inferred | |||
| Đã gửi nhắc thanh toán | Hệ thống đã tạo và gửi thông báo nhắc nợ hoặc nhắc thanh toán cho khách hàng về hóa đơn quá hạn. Sự kiện này được ghi nhận từ nhật ký lịch sử nhắc nợ. | ||
| Vì sao điều này quan trọng Giúp đánh giá hiệu quả của chiến lược thu hồi công nợ. Phân tích thời gian từ lúc nhắc thanh toán đến khi nhận tiền là yếu tố quan trọng để tính KPI Hiệu quả nhắc thanh toán. Lấy dữ liệu ở đâu Được ghi nhận trong các bảng dữ liệu nhắc nợ, cụ thể là MHNK (tiêu đề dữ liệu nhắc nợ) và MHND (các mục dữ liệu nhắc nợ), được tạo khi chạy nhắc nợ (giao dịch F150). Thu thập Được ghi nhận khi chạy nhắc nợ (F150) cho khoản quá hạn. Loại sự kiện explicit | |||
| Đã tạo hồ sơ tranh chấp | Tranh chấp chính thức đã được ghi nhận cho hóa đơn, thường do khiếu nại của khách hàng. Tranh chấp này được lưu trong hệ thống SAP Dispute Management. | ||
| Vì sao điều này quan trọng Giúp xác định hóa đơn có nguy cơ bị thanh toán chậm và làm rõ vấn đề gốc khiến khách hàng không hài lòng. Đây là điểm bắt đầu của một quy trình xử lý ngoại lệ quan trọng. Lấy dữ liệu ở đâu Được ghi nhận khi tạo hồ sơ trong bảng hồ sơ tranh chấp (UDM_CASE) liên kết với chứng từ kế toán của hóa đơn. Thu thập Được ghi nhận khi người dùng tạo hồ sơ tranh chấp qua giao dịch UDM_DISPUTE. Loại sự kiện explicit | |||
| Hóa đơn đã được điều chỉnh | Đánh dấu hoạt động làm lại khi phát hiện hóa đơn ban đầu có sai sót và sau đó bị đảo. Sự kiện này được ghi nhận bằng cách xác định chứng từ đảo liên kết với hóa đơn gốc. | ||
| Vì sao điều này quan trọng Làm rõ những điểm kém hiệu quả và vấn đề chất lượng trong quy trình. Tần suất điều chỉnh cao cho thấy dữ liệu bán hàng hoặc lập hóa đơn ở các bước trước có vấn đề, hỗ trợ dashboard Tỷ lệ làm lại và lỗi hóa đơn. Lấy dữ liệu ở đâu Xác định bằng cách tìm chứng từ đảo có trường BKPF-STBLG trỏ đến chứng từ gốc. Sự kiện là thời điểm tạo chứng từ đảo này. Thu thập Được ghi nhận khi tạo chứng từ đảo, chẳng hạn qua FB08. Loại sự kiện explicit | |||
| Hóa đơn đã được phê duyệt | Đánh dấu hóa đơn được phê duyệt chính thức, cho phép ghi sổ hoặc gửi cho khách hàng. Sự kiện này thường được suy ra khi chứng từ lưu tạm được chuyển thành chứng từ đã ghi sổ. | ||
| Vì sao điều này quan trọng Theo dõi quy trình phê duyệt nội bộ, một nguồn gây điểm nghẽn phổ biến. Phân tích hoạt động này giúp ích cho dashboard Phân tích luồng phê duyệt hóa đơn, bằng cách xác định người phê duyệt xử lý chậm. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này khi chứng từ chuyển từ trạng thái lưu tạm (trong VBKPF) sang trạng thái đã ghi sổ (trong BKPF). Nếu dùng hệ thống workflow, nhật ký workflow có thể ghi nhận sự kiện này trực tiếp. Thu thập So sánh ngày tạo chứng từ tạm (VBKPF) với ngày ghi sổ của chứng từ cuối cùng (BKPF). Loại sự kiện inferred | |||
| Hóa đơn đã được xóa nợ | Một trạng thái kết thúc khác, xảy ra khi hóa đơn được xác định là không thể thu hồi và số dư chưa thanh toán được xóa vào tài khoản nợ xấu. Hóa đơn được đóng mà không cần khách hàng thanh toán. | ||
| Vì sao điều này quan trọng Đây là kết quả tiêu cực của quy trình và gây thất thu. Theo dõi các sự kiện này giúp phân tích nguyên nhân nợ xấu và cải thiện chính sách quản lý tín dụng. Lấy dữ liệu ở đâu Được suy ra bằng cách phân tích giao dịch bù trừ hóa đơn. Nếu chứng từ bù trừ được hạch toán vào một tài khoản sổ cái chi phí nợ xấu cụ thể, hóa đơn được xem là đã xóa nợ. Thu thập Được suy ra khi giao dịch bù trừ có bút toán vào tài khoản sổ cái nợ xấu được chỉ định. Loại sự kiện inferred | |||
| Hóa đơn được lưu tạm | Chứng từ hóa đơn đã được lưu ở trạng thái tạm thời nhưng chưa ghi sổ vào sổ cái. Cách này thường được dùng khi thông tin chưa đầy đủ hoặc cần được kiểm tra trước khi ghi sổ chính thức. | ||
| Vì sao điều này quan trọng Theo dõi các bước trước khi ghi sổ và những chậm trễ có thể xảy ra. Thời gian lưu tạm kéo dài có thể cho thấy vấn đề về chất lượng dữ liệu hoặc điểm nghẽn trong quy trình phê duyệt trước. Lấy dữ liệu ở đâu Chứng từ lưu tạm được lưu trong bảng VBKPF. Hoạt động này được đánh dấu khi một chứng từ được tạo tại đây rồi ghi sổ sau đó. Thu thập Được ghi nhận khi lưu chứng từ tạm bằng giao dịch như FV70. Loại sự kiện explicit | |||
Hướng dẫn trích xuất
Các bước
- Mở ABAP Editor: Đăng nhập vào hệ thống SAP ECC. Mở ABAP Editor bằng mã giao dịch
SE38. - Tạo chương trình: Nhập tên cho chương trình mới vào trường Program, chẳng hạn
Z_PM_O2C_INVOICE_EXTRACT, rồi nhấn nút Create. Nhập tiêu đề mô tả và đặt Type của chương trình là 'Executable Program'. - Tạo màn hình chọn dữ liệu: Trong mã nguồn chương trình, khai báo các tham số trên màn hình chọn dữ liệu để người dùng lọc dữ liệu cần trích xuất. Các tham số chính gồm khoảng ngày tạo chứng từ (
S_ERDAT), mã công ty (S_BUKRS) và loại chứng từ thanh toán (S_VBTYP). - Khai báo cấu trúc dữ liệu: Khai báo cấu trúc bảng nội bộ để lưu nhật ký sự kiện cuối cùng. Cấu trúc cần có các trường
InvoiceNumber,ActivityName,EventTimevà các thuộc tính nên dùng nhưUserName,BillingDocumentType,CustomerNumber,CompanyCodevàTotalInvoiceAmount. - Viết logic chọn dữ liệu: Viết phần ABAP chính để chọn dữ liệu. Trước tiên, chọn các chứng từ thanh toán chính từ bảng
VBRKvàBKPFtheo thông tin người dùng nhập trên màn hình chọn dữ liệu. Lưu kết quả vào một bảng nội bộ tạm thời. - Trích xuất hoạt động: Duyệt danh sách chứng từ thanh toán ban đầu. Với mỗi chứng từ, tiếp tục chọn dữ liệu từ các bảng liên quan để xác định 13 hoạt động cần thiết. Ví dụ, truy vấn bảng
NASTđể tìm sự kiện 'Đã gửi hóa đơn cho khách hàng', bảngBSEGđể lấy thông tin tất toán ('Hóa đơn đã tất toán', 'Đã ghi nhận thanh toán') và bảngMHNKđể lấy dữ liệu nhắc nợ ('Đã gửi nhắc thanh toán'). - Tạo bảng nhật ký sự kiện: Với mỗi hoạt động tìm được ở bước trước, thêm một bản ghi vào bảng nội bộ nhật ký sự kiện cuối cùng. Đảm bảo ánh xạ chính xác
InvoiceNumber,ActivityName,EventTimevà các thuộc tính khác từ bảng nguồn. - Ghi lên máy chủ ứng dụng: Sau khi duyệt xong và điền đầy đủ bảng nhật ký sự kiện, dùng các câu lệnh
OPEN DATASET,LOOP AT... TRANSFERvàCLOSE DATASETđể ghi nội dung bảng nội bộ vào tệp phẳng trên máy chủ ứng dụng SAP. Chọn đường dẫn tệp logic mà bạn có quyền truy cập. - Lấy tệp: Dùng mã giao dịch
AL11để mở thư mục trên máy chủ ứng dụng và tìm tệp vừa tạo. Phối hợp với nhóm SAP Basis để tải tệp về máy tính hoặc vị trí mạng dùng chung. - Định dạng cuối cùng: Mở tệp đã tải xuống và xác nhận đây là tệp CSV phân tách bằng dấu phẩy, có hàng tiêu đề. Lưu tệp ở định dạng UTF-8 để ProcessMind có thể tải lên.
Cấu hình
- Điều kiện cần: Có quyền tạo và chạy chương trình ABAP (mã giao dịch SE38). Có quyền đọc các bảng FI và SD, gồm
VBRK,VBRP,BKPF,BSEG,NAST,MHNKvàUDM_CASE_ATTR00(dùng cho Dispute Management). - Chọn khoảng ngày: Chương trình cần có tham số bắt buộc để chọn khoảng ngày, thường dựa trên ngày tạo chứng từ (
ERDATtrong VBRK/BKPF). Khi trích xuất lần đầu, nên chọn khoảng 3-6 tháng để dữ liệu không quá lớn. - Bộ lọc chính: Luôn lọc theo
CompanyCode(BUKRS) để giới hạn phạm vi trích xuất. Bạn cũng nên lọc theo loại chứng từ thanh toán (VBTYPtừ VBRK) hoặc loại chứng từ kế toán (BLARTtừ BKPF), chỉ lấy các loại hóa đơn cần thiết. Ví dụ, dùng 'RV' cho hóa đơn kế toán thông thường và loại trừ giấy báo có hoặc chứng từ khác. - Lưu ý về hiệu suất: Với tập dữ liệu lớn kéo dài hơn vài tháng, nên chạy chương trình dưới dạng tác vụ nền để tránh hết thời gian phiên. Tối ưu ABAP bằng cách đọc bảng theo chỉ mục và tránh truy vấn cơ sở dữ liệu trong các vòng lặp lồng nhau. Nên chọn dữ liệu vào bảng nội bộ trước rồi mới xử lý.
- Cấu hình tệp đầu ra: Mã ABAP cần chỉ định đường dẫn tệp đầu ra trên máy chủ ứng dụng và ký tự phân tách trong tệp CSV, thường là dấu phẩy hoặc chấm phẩy. Đảm bảo đường dẫn trỏ đến thư mục đã cấu hình và có thể truy cập.
Truy vấn mẫu abap
REPORT Z_PM_O2C_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables
*&---------------------------------------------------------------------*
TABLES: VBRK, BKPF.
*&---------------------------------------------------------------------*
*& Type Definitions for Event Log Output
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoicenumber TYPE vbrk-vbeln,
activityname TYPE string,
eventtime TYPE timestamp,
username TYPE xubname,
billingdocumenttype TYPE vbrk-vbtyp,
customernumber TYPE vbrk-kunnr,
companycode TYPE vbrk-bukrs,
totalinvoiceamount TYPE vbrk-netwr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: BEGIN OF gs_invoice,
vbeln TYPE vbrk-vbeln, " SD Doc (Invoice)
awkey TYPE bkpf-awkey, " Accounting Doc Reference Key
bukrs TYPE vbrk-bukrs, " Company Code
kunnr TYPE vbrk-kunnr, " Customer
vbtyp TYPE vbrk-vbtyp, " SD Doc Type
netwr TYPE vbrk-netwr, " Net Value
waerk TYPE vbrk-waerk, " Currency
fkdat TYPE vbrk-fkdat, " Billing Date
erdat TYPE vbrk-erdat, " Creation Date
erzet TYPE vbrk-erzet, " Creation Time
ernam TYPE vbrk-ernam, " Creator
belnr TYPE bkpf-belnr, " Acct Doc
gjahr TYPE bkpf-gjahr, " Fiscal Year
cpudt TYPE bkpf-cpudt, " Acct Doc Entry Date
cputm TYPE bkpf-cputm, " Acct Doc Entry Time
usnam TYPE bkpf-usnam, " Acct Doc User
stblg TYPE bkpf-stblg, " Reversal Doc
END OF gs_invoice.
DATA: gt_invoices LIKE TABLE OF gs_invoice.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbrk-erdat OBLIGATORY,
s_bukrs FOR vbrk-bukrs OBLIGATORY,
s_vbtyp FOR vbrk-vbtyp.
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/trans/tmp/invoice_extract.csv' OBLIGATORY.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" 1. Select base set of invoices
SELECT vbrk~vbeln, vbrk~bukrs, vbrk~kunnr, vbrk~vbtyp, vbrk~netwr, vbrk~waerk,
vbrk~fkdat, vbrk~erdat, vbrk~erzet, vbrk~ernam,
bkpf~belnr, bkpf~gjahr, bkpf~cpudt, bkpf~cputm, bkpf~usnam, bkpf~stblg, bkpf~awkey
INTO CORRESPONDING FIELDS OF TABLE gt_invoices
FROM vbrk
INNER JOIN bkpf ON bkpf~awkey = vbrk~vbeln AND bkpf~awtyp = 'VBRK'
WHERE vbrk~erdat IN s_erdat
AND vbrk~bukrs IN s_bukrs
AND vbrk~vbtyp IN s_vbtyp.
IF gt_invoices IS INITIAL.
MESSAGE 'No invoices found for the selected criteria.' TYPE 'I'.
RETURN.
ENDIF.
LOOP AT gt_invoices INTO gs_invoice.
CLEAR gs_event_log.
gs_event_log-invoicenumber = gs_invoice-vbeln.
gs_event_log-billingdocumenttype = gs_invoice-vbtyp.
gs_event_log-customernumber = gs_invoice-kunnr.
gs_event_log-companycode = gs_invoice-bukrs.
gs_event_log-totalinvoiceamount = gs_invoice-netwr.
" Activity: Invoice Generated (using accounting doc creation)
gs_event_log-activityname = 'Invoice Generated'.
gs_event_log-username = gs_invoice-usnam.
CONCATENATE gs_invoice-cpudt gs_invoice-cputm INTO DATA(lv_ts_gen).
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Posted (same as generated for non-parked docs)
gs_event_log-activityname = 'Invoice Posted'.
gs_event_log-username = gs_invoice-usnam.
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Approved (inferred by posting)
gs_event_log-activityname = 'Invoice Approved'.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Sent To Customer
SELECT SINGLE addat, aduhr FROM nast
INTO (DATA(lv_nast_date), DATA(lv_nast_time))
WHERE kappl = 'V3' AND objky = gs_invoice-vbeln AND vszst > '0'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Sent To Customer'.
gs_event_log-username = sy-uname.
CONVERT DATE lv_nast_date TIME lv_nast_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Corrected / Reversed
IF gs_invoice-stblg IS NOT INITIAL.
SELECT SINGLE cpudt, cputm, usnam FROM bkpf
INTO (DATA(lv_rev_date), DATA(lv_rev_time), DATA(lv_rev_user))
WHERE belnr = gs_invoice-stblg AND gjahr = gs_invoice-gjahr.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Corrected'.
gs_event_log-username = lv_rev_user.
CONVERT DATE lv_rev_date TIME lv_rev_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
" Activity: Payment Applied, Cleared, Due Date, Written Off (from BSEG)
SELECT SINGLE augdt, augbl, zfBDT, hkont FROM bseg
INTO (DATA(lv_augdt), DATA(lv_augbl), DATA(lv_zfbdt), DATA(lv_hkont))
WHERE bukrs = gs_invoice-bukrs
AND belnr = gs_invoice-belnr
AND gjahr = gs_invoice-gjahr
AND koart = 'D'. " Customer line
IF sy-subrc = 0.
" Due Date Reached (Calculated event)
IF lv_zfbdt IS NOT INITIAL.
gs_event_log-activityname = 'Invoice Due Date Reached'.
gs_event_log-username = 'System'.
CONVERT DATE lv_zfbdt INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Cleared, Applied, Write-Off
IF lv_augdt IS NOT INITIAL.
SELECT SINGLE usnam, cpudt, cputm, blart FROM bkpf
INTO (DATA(lv_clear_user), DATA(lv_clear_date), DATA(lv_clear_time), DATA(lv_clear_type))
WHERE belnr = lv_augbl AND bukrs = gs_invoice-bukrs.
IF sy-subrc = 0.
gs_event_log-username = lv_clear_user.
CONVERT DATE lv_clear_date TIME lv_clear_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
IF lv_clear_type = 'DZ'. " Standard Customer Payment
gs_event_log-activityname = 'Customer Payment Received'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Payment Applied To Invoice'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Invoice Cleared'. APPEND gs_event_log TO gt_event_log.
ELSE. " Assuming other clearing doc types could be write-offs
gs_event_log-activityname = 'Invoice Written Off'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
" Activity: Payment Reminder Issued (Dunning)
SELECT COUNT(*) FROM mhnk WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
IF sy-subrc = 0 AND sy-dbcnt > 0.
SELECT SINGLE lafdn FROM mhnk
INTO DATA(lv_dunning_date)
WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
gs_event_log-activityname = 'Payment Reminder Issued'.
gs_event_log-username = 'System'.
CONVERT DATE lv_dunning_date INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Parked (Example from VBKPF, may require system specific logic)
SELECT SINGLE cpudt, cputm, usnam FROM vbkpf
INTO (DATA(lv_park_date), DATA(lv_park_time), DATA(lv_park_user))
WHERE awkey = gs_invoice-vbeln AND awsys = 'LOG' AND bstat = 'V'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Parked'.
gs_event_log-username = lv_park_user.
CONVERT DATE lv_park_date TIME lv_park_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Dispute Case Created (Requires Dispute Management module)
SELECT SINGLE create_date, create_time, create_user FROM udm_case_attr00
INTO (DATA(lv_disp_date), DATA(lv_disp_time), DATA(lv_disp_user))
WHERE [Your logic to link invoice to dispute case, e.g., via a custom field or object link].
IF sy-subrc = 0.
gs_event_log-activityname = 'Dispute Case Created'.
gs_event_log-username = lv_disp_user.
CONVERT DATE lv_disp_date TIME lv_disp_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Write data to file
*&---------------------------------------------------------------------*
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
" Header
DATA(lv_header) = 'InvoiceNumber,ActivityName,EventTime,UserName,BillingDocumentType,CustomerNumber,CompanyCode,TotalInvoiceAmount'.
TRANSFER lv_header TO p_path.
LOOP AT gt_event_log INTO gs_event_log.
DATA(lv_line) = |
{ gs_event_log-invoicenumber }|
,{ gs_event_log-activityname }|
,{ gs_event_log-eventtime }|
,{ gs_event_log-username }|
,{ gs_event_log-billingdocumenttype }|
,{ gs_event_log-customernumber }|
,{ gs_event_log-companycode }|
,{ gs_event_log-totalinvoiceamount }|.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: 'Extraction complete. File created at:', p_path. Các bước
- Điều kiện và quyền truy cập: Đảm bảo bạn có tài khoản cơ sở dữ liệu chỉ đọc các bảng SAP ECC cần thiết, gồm VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE và các bảng khác được nêu trong truy vấn. Quyền này thường chỉ cấp cho quản trị viên hệ thống hoặc một số nhóm phân tích dữ liệu.
- Kết nối cơ sở dữ liệu: Dùng công cụ SQL phổ biến như DBeaver, Oracle SQL Developer hoặc Microsoft SQL Server Management Studio để kết nối với cơ sở dữ liệu SAP ECC.
- Chuẩn bị truy vấn SQL: Sao chép toàn bộ truy vấn SQL trong phần 'query' vào trình soạn thảo của công cụ SQL.
- Thay các giá trị giữ chỗ: Truy vấn có một số giá trị giữ chỗ cần thay bằng thông tin phù hợp với môi trường của bạn. Cụ thể:
'YYYYMMDD': Thay tất cả các chỗ bằng ngày bắt đầu và kết thúc của giai đoạn cần phân tích. Hãy giới hạn khoảng thời gian để dữ liệu không quá lớn.'XXXX': Thay bằng mã công ty cần phân tích.[Your Invoice Output Type]: Nhập mã loại đầu ra dùng để gửi hóa đơn cho khách hàng, chẳng hạn 'RD00'.[Your Bad Debt G/L Account]: Nhập số tài khoản sổ cái dùng để xóa sổ các hóa đơn không thể thu hồi.[Your Dispute Case Invoice Attribute]: Nhập tên thuộc tính lưu số hóa đơn trong cấu hình Dispute Management, chẳng hạn 'INVOICE_ID'.
- Kiểm tra hàm dấu thời gian: Truy vấn dùng cú pháp chung
CAST(CONCAT(date_field, time_field) AS TIMESTAMP). Bạn có thể cần chỉnh sửa cú pháp cho phù hợp với hệ quản trị cơ sở dữ liệu, chẳng hạn dùngTO_TIMESTAMPcho Oracle hoặcDATETIMEFROMPARTScho SQL Server. - Chạy truy vấn: Chạy truy vấn đã chỉnh sửa. Tùy kích thước bảng SAP và khoảng ngày đã chọn, quá trình có thể mất nhiều thời gian.
- Kiểm tra kết quả: Khi truy vấn chạy xong, kiểm tra xem kết quả có các cột cần thiết không: InvoiceNumber, ActivityName, EventTime và các thuộc tính nên dùng. Kiểm tra lỗi hoặc kết quả trống.
- Xuất sang CSV: Xuất toàn bộ kết quả từ công cụ SQL thành tệp CSV. Lưu tệp ở định dạng UTF-8 để tránh lỗ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, xác nhận tiêu đề cột trong CSV khớp chính xác với tên thuộc tính bắt buộc, chẳng hạn
InvoiceNumber,ActivityName,EventTime,UserName.
Cấu hình
- Kết nối cơ sở dữ liệu: Cần có kết nối SQL trực tiếp, chỉ đọc đến cơ sở dữ liệu SAP ECC bên dưới. Phương pháp này bỏ qua hoàn toàn lớp ứng dụng SAP.
- Quyền truy cập: Tài khoản cơ sở dữ liệu cần có quyền
SELECTtrên tất cả các bảng trong truy vấn, thuộc các phân hệ FI, SD và có thể cả FSCM. - Khoảng ngày: Cần giới hạn truy vấn theo một khoảng ngày cụ thể để đảm bảo hiệu suất và dung lượng dữ liệu ở mức hợp lý. Nên bắt đầu với khoảng 3 đến 6 tháng. Cần điền giá trị cho
'YYYYMMDD'ở nhiều vị trí trong truy vấn. - Lọc theo mã công ty: Truy vấn được thiết kế để lọc theo mã công ty (
BUKRS). Thông thường, nên phân tích từng mã công ty hoặc một vài mã mỗi lần. - Cấu hình loại chứng từ: Logic xác định các sự kiện như sửa hóa đơn, xóa sổ hoặc gửi chứng từ phụ thuộc vào cấu hình SAP tiêu chuẩn. Bạn có thể cần chỉnh truy vấn nếu tổ chức dùng loại chứng từ tùy chỉnh (
BLART), loại đầu ra (KSCHL) hoặc tài khoản sổ cái riêng cho các quy trình này. - Lưu ý về hiệu suất: Chạy truy vấn trên hệ thống SAP đang vận hành có thể tiêu tốn nhiều tài nguyên và ảnh hưởng đến hiệu suất. Nên chạy các đợt trích xuất lớn vào giờ thấp điểm hoặc trên bản sao cơ sở dữ liệu chuyên dùng cho báo cáo.
Truy vấn mẫu sql
WITH InvoiceBase AS (
SELECT
VBRK.VBELN AS InvoiceNumber,
VBRK.FKART AS BillingDocumentType,
VBRK.KUNRG AS CustomerNumber,
VBRK.BUKRS AS CompanyCode,
VBRK.NETWR AS TotalInvoiceAmount,
VBRK.ERNAM AS CreatorName,
VBRK.ERDAT AS CreationDate,
VBRK.ERZET AS CreationTime
FROM VBRK
WHERE VBRK.ERDAT BETWEEN '20230101' AND '20231231' -- Filter by Invoice Creation Date
AND VBRK.BUKRS IN ('1000') -- Filter by Company Code
AND VBRK.FKART NOT IN ('S1', 'S2') -- Exclude cancelled invoices
)
-- 1. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS ActivityName,
CAST(CONCAT(ib.CreationDate, ib.CreationTime) AS TIMESTAMP) AS EventTime,
ib.CreatorName AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM InvoiceBase ib
UNION ALL
-- 2. Invoice Parked
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Parked' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = 'V' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 3. Invoice Posted
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Posted' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = '' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 4. Invoice Approved (from Parked to Posted)
SELECT
SUBSTRING(h.OBJECTID, 4, 10) AS InvoiceNumber,
'Invoice Approved' as ActivityName,
CAST(CONCAT(h.UDATE, h.UTIME) AS TIMESTAMP) AS EventTime,
h.USERNAME AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM CDHDR h
JOIN CDPOS p ON h.MANDANT = p.MANDANT AND h.OBJECTCLAS = p.OBJECTCLAS AND h.OBJECTID = p.OBJECTID AND h.CHANGENR = p.CHANGENR
JOIN InvoiceBase ib ON SUBSTRING(h.OBJECTID, 4, 10) = ib.InvoiceNumber
WHERE h.OBJECTCLAS = 'BELEGV'
AND p.TABNAME = 'BKPF'
AND p.FNAME = 'BSTAT'
AND p.VALUE_OLD = 'V'
AND p.VALUE_NEW = ' '
AND h.UDATE BETWEEN '20230101' AND '20231231'
UNION ALL
-- 5. Invoice Sent To Customer
SELECT
n.OBJKY AS InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
CAST(CONCAT(n.DATVR, n.UHRVR) AS TIMESTAMP) AS EventTime,
n.VSTAT AS UserName, -- User who processed is not directly available, using processing status as a proxy
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM NAST n
JOIN InvoiceBase ib ON n.OBJKY = ib.InvoiceNumber
WHERE n.KSCHL = '[Your Invoice Output Type]' -- E.g., 'RD00'
AND n.VSTAT = '1' -- Processed successfully
AND n.DATVR BETWEEN '20230101' AND '20231231'
UNION ALL
-- 6. Invoice Corrected (Reversed)
SELECT
SUBSTRING(orig_doc.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Corrected' AS ActivityName,
CAST(CONCAT(rev_doc.CPUDT, rev_doc.CPUTM) AS TIMESTAMP) AS EventTime,
rev_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
rev_doc.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF orig_doc
JOIN BKPF rev_doc ON orig_doc.STBLG = rev_doc.BELNR AND orig_doc.BUKRS = rev_doc.BUKRS AND orig_doc.GJAHR = rev_doc.STJAH
JOIN InvoiceBase ib ON SUBSTRING(orig_doc.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE orig_doc.AWTYP = 'VBRK' AND orig_doc.STBLG IS NOT NULL AND rev_doc.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 7. Invoice Due Date Reached
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Due Date Reached' AS ActivityName,
CAST(CONCAT(bs.ZFBDT, '000000') AS TIMESTAMP) AS EventTime,
'System' AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSEG bs
JOIN BKPF b ON bs.MANDT = b.MANDT AND bs.BUKRS = b.BUKRS AND bs.BELNR = b.BELNR AND bs.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND bs.KOART = 'D' AND bs.ZFBDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 8. Payment Reminder Issued
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(CONCAT(h.LAUFD, '000000') AS TIMESTAMP) AS EventTime,
h.LAUFI AS UserName, -- Dunning Run ID
ib.BillingDocumentType,
ib.CustomerNumber,
d.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM MHND d
JOIN MHNK h ON d.MANDT = h.MANDT AND d.LAUFD = h.LAUFD AND d.LAUFI = h.LAUFI
JOIN BKPF b ON d.MANDT = b.MANDT AND d.BUKRS = b.BUKRS AND d.BELNR = b.BELNR AND d.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE h.LAUFD BETWEEN '20230101' AND '20231231'
UNION ALL
-- 9. Dispute Case Created
SELECT
attr.ATTR_VALUE AS InvoiceNumber,
'Dispute Case Created' AS ActivityName,
sc.CREATE_TIME AS EventTime,
sc.CREATED_BY AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM SCMG_T_CASE_ATTR attr
JOIN SCASE sc ON attr.CASE_GUID = sc.CASE_GUID
JOIN InvoiceBase ib ON attr.ATTR_VALUE = ib.InvoiceNumber
WHERE attr.ATTR_NAME = '[Your Dispute Case Invoice Attribute]' -- e.g., 'INVOICE_ID'
AND CAST(sc.CREATE_TIME AS DATE) BETWEEN '20230101' AND '20231231'
UNION ALL
-- 10, 11, 12. Clearing Events (Payment, Clearing, Write-Off)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
BillingDocumentType,
CustomerNumber,
CompanyCode,
TotalInvoiceAmount
FROM (
SELECT
bsad.XBLNR AS InvoiceNumber,
CASE
WHEN clearing_item.HKONT = '[Your Bad Debt G/L Account]' THEN 'Invoice Written Off'
ELSE 'Customer Payment Received'
END AS ActivityName,
CAST(CONCAT(clearing_doc.CPUDT, clearing_doc.CPUTM) AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
LEFT JOIN BSEG clearing_item ON clearing_doc.MANDT = clearing_item.MANDT AND clearing_doc.BUKRS = clearing_item.BUKRS AND clearing_doc.BELNR = clearing_item.BELNR AND clearing_doc.GJAHR = clearing_item.GJAHR AND clearing_item.HKONT = '[Your Bad Debt G/L Account]' -- e.g. '148000'
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Payment Applied To Invoice' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '000000') AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Invoice Cleared' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '235959') AS TIMESTAMP) AS EventTime, -- Add time to separate from 'Payment Applied'
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
) AS ClearingEvents Các bước
- Điều kiện cần: Đảm bảo bạn có giấy phép cho công cụ ETL tích hợp SAP Connector được chứng nhận, chẳng hạn Informatica PowerCenter với SAP Connector hoặc Talend với SAP Connector. Kiểm tra tài khoản SAP có đủ quyền đọc các bảng tài chính, bán hàng và hệ thống cần thiết (BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS).
- Kết nối SAP: Trong công cụ ETL, tạo kết nối mới đến hệ thống SAP ECC. Cấu hình thông tin kết nối, gồm máy chủ ứng dụng, số hệ thống, client, tên người dùng và mật khẩu. Kiểm tra để đảm bảo kết nối hoạt động.
- Chọn nguồn dữ liệu: Với mỗi hoạt động cần trích xuất, chọn các bảng SAP tương ứng làm nguồn dữ liệu trong tác vụ ETL. Ví dụ, thêm VBRK để lấy dữ liệu tạo hóa đơn, BKPF cho sự kiện hạch toán và NAST cho trao đổi với khách hàng.
- Tạo logic trích xuất cho từng hoạt động: Tạo luồng dữ liệu hoặc bước chuyển đổi riêng cho từng hoạt động trong số 13 hoạt động cần thiết. Trong mỗi luồng, lọc để chọn các bản ghi phù hợp. Ví dụ, lọc theo mã công ty (BUKRS), loại chứng từ (BLART) và khoảng ngày cụ thể, chẳng hạn ngày tạo ERDAT.
- Ánh xạ trường và chuyển đổi dữ liệu: Trong mỗi luồng dữ liệu, ánh xạ các trường bảng SAP nguồn sang cấu trúc nhật ký sự kiện đích: InvoiceNumber, ActivityName, EventTime, UserName và các thuộc tính nên dùng khác. Dùng logic chuyển đổi để đặt sẵn 'ActivityName' cho từng luồng và định dạng ngày, dấu thời gian chính xác.
- Xử lý hoạt động phức tạp: Với các sự kiện cần tính như 'Đã đến ngày thanh toán hóa đơn', dùng ngày thanh toán cơ sở (ZFBDT) và logic điều khoản thanh toán để tính ngày đến hạn, hoặc lấy trực tiếp ngày đến hạn ròng (NETDT) từ BSEG. Với sự kiện lấy từ nhật ký thay đổi như 'Đã duyệt hóa đơn', bạn có thể cần kết hợp các bảng như BKPF và CDHDR/CDPOS theo số chứng từ và ngày.
- Gộp dữ liệu hoạt động: Dùng phép chuyển đổi 'Union' hoặc 'Merge' trong công cụ ETL để gộp đầu ra của cả 13 luồng dữ liệu thành một tập dữ liệu. Trước khi gộp, hãy đảm bảo tên cột và kiểu dữ liệu nhất quán giữa các luồng.
- Cấu hình đích đầu ra: Chọn nơi lưu nhật ký sự kiện cuối cùng. Có thể dùng tệp phẳng (CSV), bảng cơ sở dữ liệu hoặc kết nối trực tiếp đến khu vực trung gian.
- Lên lịch trích xuất: Đặt tham số khoảng ngày cho lần trích xuất. Với lần tải đầu tiên, bạn có thể lấy dữ liệu trong 6-12 tháng. Với các lần tải phần dữ liệu mới tiếp theo, hãy đặt tác vụ trích xuất dữ liệu kể từ ngày chạy gần nhất.
- Chạy và xuất dữ liệu: Chạy tác vụ ETL. Khi hoàn tất, kiểm tra tệp đầu ra để đảm bảo đúng định dạng. Kết quả cần là một tệp CSV duy nhất, mỗi hàng là một sự kiện riêng, sẵn sàng tải lên ProcessMind.
Cấu hình
- Kết nối SAP: Cần có kết nối máy chủ ứng dụng đến hệ thống SAP ECC đích. Tài khoản SAP cần quyền RFC và quyền truy cập các bảng như VBRK, BKPF, BSEG, NAST cùng các bảng khác được nêu trong truy vấn.
- Giấy phép công cụ ETL: Bắt buộc phải có giấy phép hợp lệ cho công cụ ETL thương mại và SAP Connector tương ứng.
- Khoảng ngày: Nên trích xuất dữ liệu trong khoảng 3 đến 6 tháng để có mẫu đại diện cho việc phân tích mà không làm hệ thống quá tải. Dùng tham số có thể cấu hình cho ngày bắt đầu và ngày kết thúc.
- Bộ lọc chính: Luôn lọc theo mã công ty (BUKRS) để giới hạn phạm vi trích xuất. Cũng cần lọc theo loại chứng từ thanh toán phù hợp (VBRK-FKART) và loại chứng từ kế toán (BKPF-BLART), chỉ lấy hóa đơn thông thường và loại trừ các loại chứng từ khác như giấy báo có hoặc chứng từ nội bộ.
- Hiệu suất: Trích xuất dữ liệu từ các bảng lớn như BSEG có thể chậm. Hãy dùng bộ lọc phù hợp, tránh lấy các trường không cần thiết và lên lịch trích xuất vào giờ thấp điểm để giảm ảnh hưởng đến hiệu suất hệ thống SAP nguồn.
Truy vấn mẫu config
// ETL Data Extraction Logic for SAP Order-to-Cash Invoicing
// This represents the configuration logic within a graphical ETL tool.
// == Global Parameters ==
// $StartDate: '[Start Date]' (e.g., '2023-01-01')
// $EndDate: '[End Date]' (e.g., '2023-06-30')
// $CompanyCodes: '[Company Code(s)]' (e.g., '1000', '2000')
// $BillingDocTypes: '[Billing Document Type(s)]' (e.g., 'F1', 'F2')
// == Source 1: Invoice Generated ==
// Tables: VBRK
DATA_SOURCE generated_invoices FROM VBRK WHERE
ERDAT >= $StartDate AND ERDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND FKART IN ($BillingDocTypes)
MAP {
InvoiceNumber: VBELN,
ActivityName: 'Invoice Generated',
EventTime: ERDAT + ERZET, // Combine date and time
UserName: ERNAM,
BillingDocumentType: FKART,
CustomerNumber: KUNAG,
CompanyCode: BUKRS,
TotalInvoiceAmount: NETWR
}
// == Source 2: Invoice Posted ==
// Tables: BKPF joined with VBRK
DATA_SOURCE posted_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Posted',
EventTime: A.BUDAT + A.CPUTM, // Posting date and entry time
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 3: Invoice Parked ==
// Tables: BKPF joined with VBRK
DATA_SOURCE parked_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.CPUDT >= $StartDate AND A.CPUDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = 'V'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Parked',
EventTime: A.CPUDT + A.CPUTM,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 4: Invoice Approved (Transition from Parked to Posted) ==
// Tables: BKPF joined with VBRK
DATA_SOURCE approved_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
AND EXISTS (SELECT 1 FROM VBELEGV C WHERE C.BELNR = A.BELNR) // Check if it was ever parked
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Approved',
EventTime: A.BUDAT + A.CPUTM, // Use posting date as approval date
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 5: Invoice Sent To Customer ==
// Tables: NAST joined with VBRK
DATA_SOURCE sent_invoices FROM NAST as A
INNER JOIN VBRK as B ON (A.OBJKY = B.VBELN)
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND B.BUKRS IN ($CompanyCodes)
AND A.VSTAT = '1' // Successfully processed
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Sent To Customer',
EventTime: A.ERDAT + A.ERUHR,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: B.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 6: Invoice Corrected (Reversed) ==
// Tables: VBRK (for the reversal document)
DATA_SOURCE corrected_invoices FROM VBRK as A
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.SFAKN <> '' // SFAKN is the original cancelled invoice
MAP {
InvoiceNumber: A.SFAKN, // Case ID is the original invoice
ActivityName: 'Invoice Corrected',
EventTime: A.ERDAT + A.ERZET,
UserName: A.ERNAM,
BillingDocumentType: A.FKART,
CustomerNumber: A.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: NULL // Amount belongs to the reversal doc, not original
}
// == Source 7: Invoice Due Date Reached ==
// Tables: BSEG joined with VBRK
DATA_SOURCE due_invoices FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.NETDT >= $StartDate AND A.NETDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.KOART = 'D' // Customer line item
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Due Date Reached',
EventTime: A.NETDT, // Net due date
UserName: 'System',
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 8: Payment Reminder Issued ==
// Tables: MHNK, MHND, VBRK
DATA_SOURCE reminders FROM MHNK as A
INNER JOIN MHND as D ON (A.LAUFD = D.LAUFD AND A.LAUFI = D.LAUFI)
INNER JOIN VBRK as B ON (SUBSTRING(D.XBLNR, 1, 10) = B.VBELN) // XBLNR may need parsing
WHERE A.LAUFD >= $StartDate AND A.LAUFD <= $EndDate
AND D.BUKRS IN ($CompanyCodes)
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Reminder Issued',
EventTime: A.LAUFD, // Dunning date
UserName: A.IDAPS,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: D.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 9: Dispute Case Created ==
// Tables: UDM_CASE_ATTR00
DATA_SOURCE disputes FROM UDM_CASE_ATTR00 as A
WHERE A.CREATE_TIMESTAMP >= $StartDate // Timestamp format may vary
AND A.FIN_COMP_CODE IN ($CompanyCodes)
AND A.PROCESS = 'FIN_FSCM_DIS'
MAP {
InvoiceNumber: A.BILL_DOC_ID,
ActivityName: 'Dispute Case Created',
EventTime: A.CREATE_TIMESTAMP,
UserName: A.CREATE_USER,
BillingDocumentType: NULL,
CustomerNumber: A.BP_NUMBER,
CompanyCode: A.FIN_COMP_CODE,
TotalInvoiceAmount: A.DISPUTED_AMOUNT
}
// == Source 10: Customer Payment Received ==
// Tables: BKPF
DATA_SOURCE payments FROM BKPF
WHERE BUDAT >= $StartDate AND BUDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND BLART = 'DZ' // Example for Customer Payment
MAP {
InvoiceNumber: NULL, // Invoice not yet known
ActivityName: 'Customer Payment Received',
EventTime: BUDAT + CPUTM,
UserName: USNAM,
BillingDocumentType: NULL,
CustomerNumber: NULL, // Requires join to BSEG to get customer
CompanyCode: BUKRS,
TotalInvoiceAmount: NULL
}
// == Source 11 & 12: Payment Applied To Invoice & Invoice Cleared ==
// Tables: BSEG joined with VBRK
DATA_SOURCE cleared_items FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.AUGBL <> ''
// Generate two records from this source
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Applied To Invoice',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM, // User from header of original invoice doc
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
UNION WITH {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Cleared',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 13: Invoice Written Off ==
// Tables: BSEG (for the invoice line) and BKPF (for clearing doc type)
DATA_SOURCE written_off FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
INNER JOIN BKPF as C ON (A.AUGBL = C.BELNR AND A.BUKRS = C.BUKRS AND A.AUGGJ = C.GJAHR)
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND C.BLART = '[Your Write-Off Document Type]' // e.g., 'AB'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Written Off',
EventTime: A.AUGDT,
UserName: C.USNAM, // User who posted the write-off
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Final Union of all sources ==
OUTPUT generated_invoices
UNION ALL posted_invoices
UNION ALL parked_invoices
UNION ALL approved_invoices
UNION ALL sent_invoices
UNION ALL corrected_invoices
UNION ALL due_invoices
UNION ALL reminders
UNION ALL disputes
UNION ALL payments
UNION ALL cleared_items
UNION ALL written_off Bạn đã sẵn sàng bắt đầu chưa?
Dùng mẫu này để chuẩn bị dữ liệu nhanh hơn và tìm ra thông tin hữu ích về quy trình lập hóa đơn, thanh toán. Bắt đầu cải thiện dòng tiền ngay hôm nay.
Thu tiền nhanh hơn: Cải thiện quy trình lập hóa đơn và thanh toán ngay hôm nay!
Loại bỏ khâu kém hiệu quả, rút ngắn 30% thời gian xử lý và cải thiện dòng tiền.
Không cần thẻ tín dụng. Bắt đầu cải thiện quy trình chỉ trong vài phút.