Mẫu dữ liệu Order-to-Cash: thanh toán và lập hóa đơn
Mẫu dữ liệu Order-to-Cash: thanh toán và lập hóa đơn
- Các thuộc tính nên thu thập
- Các hoạt động chính cần theo dõi
- Hướng dẫn trích xuất dữ liệu từ SAP S/4HANA
Các thuộc tính của quy trình Order-to-Cash: thanh toán và lập hóa đơn
| Tên | Mô tả | ||
|---|---|---|---|
| Số hóa đơn InvoiceNumber | Mã định danh duy nhất của chứng từ thanh toán, được 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òn gọi là số chứng từ thanh toán trong SAP, là mã duy nhất của mỗi giao dịch lập hóa đơn. Đây là khóa trung tâm liên kết mọi hoạt động liên quan, từ tạo và hạch toán hóa đơn đến nhận và đối soát khoản thanh toán. Trong process mining, thuộc tính này rất cần thiết để liên kết các sự kiện với từng hồ sơ. Tất cả sự kiện có cùng Số hóa đơn được nhóm vào một phiên bản quy trình, giúp phân tích toàn bộ vòng đời của từng hóa đơn từ đầu đến cuối. Nhờ đó, bạn có thể theo dõi thời gian chu kỳ, phát hiện sai lệch và phân tích hành trình của từng hóa đơn. Vì sao điều này quan trọng Đây là mã định danh cốt lõi, liên kết mọi hoạt động lập hóa đơn liên quan vào cùng một hồ sơ, giúp phân tích quy trình từ đầu đến cuối. Lấy dữ liệu ở đâu Bảng SAP: VBRK, Trường: VBELN Ví dụ 900012349000567890009012 | |||
| Tên hoạt động ActivityName | Tên hoạt động nghiệp vụ hoặc sự kiện xảy ra trong quy trình lập hóa đơn, chẳng hạn như 'Hóa đơn được tạo' hoặc 'Đã nhận thanh toán'. | ||
| Mô tả Tên hoạt động mô tả một bước hoặc cột mốc cụ thể trong vòng đời lập hóa đơn. Các hoạt động này được xác định từ nhiều nguồn dữ liệu trong SAP, như mã giao dịch, thay đổi trạng thái chứng từ hoặc mục nhật ký cụ thể, để tạo thành luồng quy trình theo trình tự. Phân tích trình tự và tần suất của các hoạt động là trọng tâm của process mining. Việc này giúp trực quan hóa sơ đồ quy trình, tìm ra các biến thể phổ biến và hiếm gặp, xác định điểm nghẽn giữa các bước, đồng thời đo tần suất của những hoạt động không tạo thêm giá trị như làm lại hoặc hủy. 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 luồng, biến thể cũng như điểm nghẽn. Lấy dữ liệu ở đâu Được tổng hợp từ nhiều nguồn, gồm mã giao dịch (SY-TCODE), trạng thái chứng từ thay đổi (bảng CDHDR/CDPOS) hoặc nhật ký workflow nghiệp vụ, chẳng hạn SWW_WI2OBJ. Ví dụ Hóa đơn được tạoHóa đơn được hạch toán vào kế toánĐã nhận thanh toán từ khách hàngHóa đơn bị hủy | |||
| Thời điểm sự kiện EventTime | Dấu thời gian chính xác cho biết thời điểm một hoạt động hoặc sự kiện xảy ra. | ||
| Mô tả Thời điểm sự kiện cung cấp ngày giờ của từng hoạt động, tạo nên trình tự thời gian của quy trình. Dấu thời gian này rất quan trọng để tính thời lượng, thời gian chu kỳ và thời gian chờ giữa các bước trong quy trình lập hóa đơn. Khi phân tích, Thời điểm sự kiện được dùng để sắp xếp hoạt động theo trình tự, tính các KPI quan trọng như số ngày phải thu và thời gian chu kỳ lập hóa đơn, đồng thời phát hiện điểm nghẽn liên quan đến thời gian. Nhờ đó, bạn có thể theo dõi quy trình thay đổi ra sao theo thời gian và mỗi giai đoạn của chu kỳ lập hóa đơn kéo dài bao lâu. Vì sao điều này quan trọng Thuộc tính này cung cấp trình tự thời gian của các sự kiện, cần thiết để tính mọi chỉ số dựa trên thời gian như thời gian chu kỳ và thời lượng. Lấy dữ liệu ở đâu Được trích xuất từ nhiều trường ngày giờ tùy theo hoạt động, chẳng hạn ngày và giờ tạo (VBRK-ERDAT, VBRK-ERZET), dấu thời gian thay đổi (CDHDR-UDATE, CDHDR-UTIME) hoặc ngày hạch toán (BKPF-BUDAT). Ví dụ 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Giá trị hóa đơn InvoiceAmount | Tổng giá trị thuần của hóa đơn. | ||
| Mô tả Thuộc tính này thể hiện tổng giá trị hàng hóa hoặc dịch vụ được lập hóa đơn, chưa bao gồm thuế. Đây là dữ liệu tài chính cơ bản của mỗi hồ sơ hóa đơn. Giá trị hóa đơn được dùng trong nhiều loại phân tích. Thuộc tính này giúp phân nhóm quy trình theo giá trị, chẳng hạn để xem hóa đơn giá trị cao có được xử lý khác hoặc thường bị chậm hơn không. Đây cũng là cơ sở cho báo cáo tài chính và tính tổng giá trị các khoản phải thu chưa thanh toán. Vì sao điều này quan trọng Thuộc tính này cho biết giá trị tài chính của từng hóa đơn, giúp phân tích theo giá trị, ưu tiên thu hồi công nợ và đánh giá tác động tài chính. Lấy dữ liệu ở đâu Bảng SAP: VBRK, Trường: NETWR Ví dụ 1500.0025000.50125.75 | |||
| Khu vực Region | Khu vực địa lý của khách hàng. | ||
| Mô tả Thuộc tính Khu vực cho biết địa bàn địa lý, chẳng hạn bang hoặc tỉnh, gắn với địa chỉ khách hàng. Dữ liệu này thường nằm trong hồ sơ dữ liệu chủ khách hàng. Thuộc tính này là cơ sở cho dashboard hiệu quả lập hóa đơn theo khu vực. Bạn có thể so sánh các chỉ số quan trọng như thời gian chu kỳ, tỷ lệ lỗi và DSO giữa các khu vực. Qua đó, bạn có thể phát hiện khác biệt về cách thực hiện quy trình, mức độ tuân thủ hoặc hiệu quả, rồi tập trung cải tiến và chuẩn hóa các cách làm hiệu quả. Vì sao điều này quan trọng Thuộc tính này giúp so sánh hiệu quả lập hóa đơn giữa các khu vực địa lý, phát hiện chênh lệch và chuẩn hóa quy trình. Lấy dữ liệu ở đâu Được lấy từ bảng dữ liệu chủ khách hàng KNA1 (Trường: REGIO), liên kết qua mã người trả tiền trong tiêu đề hóa đơn (VBRK-KUNRG). Ví dụ CANYTXBA | |||
| Ngày đến hạn thanh toán PaymentDueDate | Ngày khách hàng dự kiến thanh toán hóa đơn. | ||
| Mô tả Ngày đến hạn thanh toán được tính dựa trên ngày hóa đơn và điều khoản thanh toán đã thỏa thuận. Đây là hạn cuối để nhận tiền trước khi hóa đơn bị xem là quá hạn. Thuộc tính này rất cần thiết để theo dõi hiệu quả thu hồi công nợ và dự báo dòng tiền. Thuộc tính được dùng trực tiếp để tính KPI tỷ lệ thanh toán đúng hạn và phân nhóm hóa đơn trong báo cáo tuổi nợ. Phân tích chênh lệch giữa ngày đến hạn và ngày thanh toán thực tế giúp đánh giá hiệu quả của các điều khoản thanh toán khác nhau. Vì sao điều này quan trọng Thuộc tính này xác định hạn thanh toán của khách hàng, rất quan trọng để tính tỷ lệ thanh toán đúng hạn và quản lý các khoản phải thu. Lấy dữ liệu ở đâu Ngày này không được lưu trực tiếp mà được tính dựa trên Ngày hóa đơn (VBRK-FKDAT) và mã Điều khoản thanh toán (VBRK-ZTERM), bằng các hàm xác định ngày tiêu chuẩn của SAP. Ví dụ 2023-04-192023-05-012023-06-17 | |||
| Ngày hóa đơn InvoiceDate | Ngày chính thức phát hành hóa đơn cho khách hàng. | ||
| Mô tả Ngày hóa đơn, còn gọi là ngày lập hóa đơn trong SAP, là mốc bắt đầu cho nhiều phép tính tài chính. Ngày này được dùng để xác định điều khoản thanh toán, ngày đến hạn và thời gian khoản phải thu còn chưa được thanh toán. Đây là thuộc tính quan trọng ở cấp hồ sơ để phân tích tài chính. Ngày hóa đơn là cơ sở tính KPI số ngày phải thu (DSO) và lập báo cáo tuổi nợ của các hóa đơn chưa thanh toán, những công cụ thiết yếu để quản lý dòng tiền và thu hồi công nợ. Vì sao điều này quan trọng Đây là ngày cơ sở cho các phép tính tài chính, dùng để xác định DSO, ngày đến hạn thanh toán và tuổi nợ của hóa đơn. Lấy dữ liệu ở đâu Bảng SAP: VBRK, Trường: FKDAT Ví dụ 2023-03-202023-04-012023-05-18 | |||
| Tên khách hàng CustomerName | Tên khách hàng được phát hành hóa đơn. | ||
| Mô tả Thuộc tính này xác định tên pháp lý của khách hàng được lập hóa đơn. Dữ liệu được lấy từ dữ liệu chủ khách hàng trong SAP. Phân tích quy trình theo khách hàng giúp phát hiện các xu hướng riêng của từng tài khoản. Chẳng hạn, bạn có thể biết khách hàng nào thường xuyên thanh toán trễ, khách hàng nào hay phát sinh tranh chấp nhất hoặc quy trình lập hóa đơn cho khách hàng nào kém hiệu quả nhất. Từ đó, bạn có thể 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 đối tượng. Vì sao điều này quan trọng Thuộc tính này hỗ trợ phân tích theo từng khách hàng, giúp xác định thói quen thanh toán, tần suất tranh chấp và điểm kém hiệu quả trong quy trình của từng tài khoản. Lấy dữ liệu ở đâu Được lấy từ bảng dữ liệu chủ khách hàng KNA1 (Trường: NAME1), liên kết qua mã người trả tiền trong tiêu đề hóa đơn (VBRK-KUNRG). Ví dụ Nhà máy điện SpringfieldCửa hàng Kwik-E-MartHệ thống Cyberdyne | |||
| Tên người dùng UserName | Mã người dùng của nhân viên thực hiện hoạt động. | ||
| Mô tả Thuộc tính này ghi nhận mã người dùng SAP chịu trách nhiệm cho một sự kiện cụ thể, chẳng hạn tạo hóa đơn, hạch toán chứng từ hoặc tất toán khoản thanh toán. Thuộc tính liên kết các bước trong quy trình với cá nhân hoặc nhóm thực hiện. Phân tích theo Tên người dùng giúp xác định cá nhân có hiệu suất tốt, nhu cầu đào tạo hoặc tình trạng phân bổ công việc chưa cân đối. Thuộc tính này cũng rất quan trọng khi phân tích tuân thủ, vì cho biết ai đã thực hiện các hoạt động quan trọng và giúp tìm hiểu vì sao những người dùng khác nhau thực hiện cùng một quy trình theo cách khác nhau. Vì sao điều này quan trọng Thuộc tính này liên kết hoạt động trong quy trình với từng người dùng cụ thể, giúp phân tích khối lượng công việc, hiệu suất và mức độ tuân thủ ở cấp cá nhân hoặc nhóm. Lấy dữ liệu ở đâu Với sự kiện tạo, thông tin này nằm trong VBRK-ERNAM. Với các thay đổi sau đó, thông tin có trong bảng lịch sử thay đổi như CDHDR-USERNAME hoặc trong nhật ký workflow. Ví dụ CBURNSHSIMPSONLLEONARD | |||
| Thời điểm kết thúc EndTime | Dấu thời gian chính xác cho biết một hoạt động hoặc sự kiện đã 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 process mining, thời điểm này thường được suy ra từ thời điểm bắt đầu của hoạt động tiếp theo trong cùng một trường hợp. Nếu hệ thống ghi lại cả sự kiện bắt đầu và kết thúc, bạn cũng có thể lấy trực tiếp thời điểm này. Thuộc tính này cần thiết để tính thời gian xử lý của từng hoạt động. Lấy thời điểm kết thúc trừ thời điểm bắt đầu sẽ cho biết thời lượng của mỗi bước. Đây là thông tin quan trọng để phân tích điểm nghẽn, chẳng hạn xác định chậm trễ ở bước phê duyệt hóa đơn. Vì sao điều này quan trọng Thuộc tính này giúp tính chính xác thời lượng xử lý của từng hoạt động, yếu tố cốt lõi để phân tích điểm nghẽn. Lấy dữ liệu ở đâu Đây là thuộc tính được suy ra để dùng trong process mining. Thông thường, thuộc tính này được tính bằng thời điểm bắt đầu của sự kiện tiếp theo trong chuỗi sự kiện của cùng một trường hợp. Trong một số tình huống, các bảng cụ thể có thể ghi lại thời điểm hoàn tất. Ví dụ 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Điều khoản thanh toán PaymentTerms | Mã xác định điều khoản thanh toán, chẳng hạn thời hạn được phép để thanh toán. | ||
| Mô tả Điều khoản thanh toán là các điều kiện đã thống nhất trước với khách hàng, quy định thời điểm đến hạn thanh toán hóa đơn. Ví dụ: “Net 30” (thanh toán trong vòng 30 ngày) hoặc “2/10 Net 30” (được giảm giá 2% nếu thanh toán trong 10 ngày, nếu không thì phải thanh toán trong vòng 30 ngày). Phân tích theo điều khoản thanh toán giúp đánh giá mức độ hiệu quả của từng điều khoản. Bằng cách đối chiếu các điều khoản khác nhau với thời gian thực tế để nhận tiền, doanh nghiệp có thể xác định điều khoản nào khuyến khích khách hàng thanh toán đúng hạn tốt nhất, rồi điều chỉnh để cải thiện dòng tiền. Vì sao điều này quan trọng Thuộc tính này xác định lịch thanh toán đã thống nhất, giúp phân tích điều khoản nào hiệu quả nhất trong việc đảm bảo khách hàng thanh toán đúng hạn. Lấy dữ liệu ở đâu Bảng SAP: VBRK, trường: ZTERM Ví dụ Z030Z060ZB60 | |||
| Hệ thống nguồn SourceSystem | Xác định hệ thống nguồn cụ thể nơi dữ liệu được trích xuất. | ||
| Mô tả Thuộc tính này cho biết dữ liệu bắt nguồn từ đâu, đặc biệt hữu ích khi có nhiều hệ thống SAP hoặc các hệ thống tích hợp khác. Giá trị thường gồm mã hệ thống và mã máy khách. Khi phân tích, thuộc tính này giúp phân biệt quy trình và hiệu quả giữa các hệ thống hoặc đơn vị trong tổ chức. Thuộc tính cũng giúp theo dõi nguồn gốc dữ liệu và cung cấp ngữ cảnh, nhất là khi kết hợp dữ liệu từ nhiều nguồn để có cái nhìn đầy đủ về quy trình. Vì sao điều này quan trọng Thuộc tính này cung cấp ngữ cảnh quan trọng về nguồn gốc dữ liệu, giúp phân biệt rõ dữ liệu trong môi trường nhiều hệ thống và hỗ trợ quản trị dữ liệu. Lấy dữ liệu ở đâu Đây thường là giá trị cố định được xác định khi trích xuất dữ liệu, thường kết hợp mã hệ thống (SY-SYSID) và mã máy khách (SY-MANDT). Ví dụ S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian cho biết dữ liệu của sự kiện này được trích xuất hoặc làm mới lần cuối khi nào. | ||
| Mô tả Thuộc tính này ghi lại ngày giờ lấy dữ liệu gần nhất từ hệ thống nguồn. Đây là trường siêu dữ liệu quan trọng, giúp bạn biết dữ liệu đang phân tích có mới hay không. Thông tin này được dùng để kiểm tra mức độ cập nhật của phân tích và quản lý lịch làm mới dữ liệu. Nhờ đó, các bên liên quan biết dữ liệu được cập nhật đến thời điểm nào khi đưa ra quyết định dựa trên dashboard và thông tin phân tích từ process mining. Vì sao điều này quan trọng Thuộc tính này cho biết dữ liệu mới đến đâu, yếu tố quan trọng để tin cậy kết quả phân tích và hiểu mức độ phù hợp của kết quả với tình hình vận hành hiện tại. Lấy dữ liệu ở đâu Dấu thời gian này được tạo và gắn vào từng bản ghi trong quá trình trích xuất và tải dữ liệu (ETL). Ví dụ 2023-06-01T02:00:00Z2023-06-02T02: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 chứng từ hủy. | ||
| Mô tả Loại chứng từ thanh toán là trường quan trọng để phân loại giao dịch trong quy trình thanh toán. Trường này kiểm soát cách xử lý chứng từ, bao gồm dải số chứng từ và quy tắc hạch toán kế toán. Thuộc tính này giúp lọc quy trình để phân tích từng loại giao dịch. Chẳng hạn, bạn có thể tạo một góc nhìn quy trình riêng cho giấy báo có để tìm hiểu lý do và luồng xử lý các điều chỉnh tài chính. Bạn cũng có thể phân tích riêng hóa đơn thông thường và chứng từ hủy để hiểu rõ hơn quy trình thanh toán chính. Vì sao điều này quan trọng Thuộc tính này phân loại giao dịch, giúp tập trung phân tích các luồng chứng từ cụ thể như hóa đơn thông thường, giấy báo có hoặc chứng từ hủy. Lấy dữ liệu ở đâu Bảng SAP: VBRK, trường: FKART Ví dụ F2G2S1L2 | |||
| Lý do khiếu nại CustomerDisputeReason | Lý do khách hàng đưa ra khi khiếu nại hóa đơn. | ||
| Mô tả Khi khách hàng khiếu nại hóa đơn, lý do thường được ghi lại. Có thể là sai giá, sai số lượng hoặc hàng hóa bị hư hỏng. Thông tin này có thể được lưu trong phân hệ SAP Dispute Management hoặc dưới dạng ghi chú văn bản. Phân tích lý do khiếu nại là bước quan trọng để tính KPI tỷ lệ lỗi thanh toán và tìm hiểu các lỗi liên quan. Việc này giúp xác định nguyên nhân gốc rễ của sai sót trong hóa đơn, từ đó doanh nghiệp có thể xử lý vấn đề mang tính hệ thống ở các quy trình trước đó, nâng cao chất lượng hóa đơn và cải thiện mức độ hài lòng của khách hàng. Vì sao điều này quan trọng Thuộc tính này cho biết lý do hóa đơn bị khiếu nại, giúp xác định trực tiếp nguyên nhân gốc rễ của lỗi thanh toán và sự không hài lòng của khách hàng. Lấy dữ liệu ở đâu Nếu sử dụng SAP Dispute Management, bạn có thể tìm thông tin này trong các bảng như UDM_DISPUTE. Nếu không, thông tin có thể được suy ra từ mã lý do trên chứng từ liên quan hoặc từ các trường văn bản. Ví dụ Sai giáSai lệch số lượngNhận hàng bị hư hỏng | |||
| Lý do lập giấy báo có CreditMemoReason | Mã lý do cho biết vì sao giấy báo có được lập. | ||
| Mô tả Khi hóa đơn có sai sót và cần điều chỉnh giảm, doanh nghiệp thường gán lý do cho chứng từ giấy báo có. Nhờ đó, có thể phân loại nguyên nhân lỗi thanh toán theo một cấu trúc thống nhất. Thuộc tính này hỗ trợ trực tiếp KPI tỷ lệ lỗi thanh toán. Bằng cách tổng hợp và phân tích lý do lập giấy báo có, doanh nghiệp có thể xác định các lỗi thường gặp nhất, chẳng hạn sai giá hoặc hàng bị trả lại. Kết quả phân tích giúp cải tiến quy trình, giảm nhu cầu điều chỉnh tài chính và làm lại. Vì sao điều này quan trọng Thuộc tính này phân loại lý do điều chỉnh giảm, giúp xác định các nguồn gây lỗi thanh toán thường gặp nhất và cải thiện chất lượng. Lấy dữ liệu ở đâu Bảng SAP: VBRK, trường: AUGRU (lý do đơn hàng). Trường này được dùng cho yêu cầu lập giấy báo có hoặc giấy báo nợ, sau đó các yêu cầu này được lập hóa đơn. Ví dụ 001 - Chênh lệch giá002 - Chất lượng kém005 - Khách hàng trả hàng | |||
| Mã công ty CompanyCode | Đơn vị tổ chức dùng để ghi nhận giao dịch tài chính. | ||
| Mô tả Mã công ty là một đơn vị tổ chức cơ bản trong SAP Financials, đại diện cho một công ty độc lập về mặt pháp lý và lập báo cáo tài chính riêng. Mỗi chứng từ thanh toán được gán cho một mã công ty cụ thể. Trong tổ chức có nhiều công ty, việc phân tích theo mã công ty rất cần thiết để so sánh hiệu quả quy trình, các chỉ số tài chính như DSO và mức độ tuân thủ giữa các pháp nhân. Mã công ty cũng là bộ lọc cấp cao cho tất cả dashboard quy trình. Vì sao điều này quan trọng Thuộc tính này cho phép phân tích quy trình theo từng pháp nhân, giúp so sánh hiệu quả và hợp nhất số liệu tài chính trong toàn tổ chức. Lấy dữ liệu ở đâu Bảng SAP: VBRK, trường: BUKRS Ví dụ 10002000US01 | |||
| Số đơn hàng bán SalesOrderNumber | Mã định danh của đơn hàng bán ban đầu dẫn đến hóa đơn. | ||
| Mô tả Số đơn hàng bán liên kết chứng từ thanh toán với các hoạt động bán hàng trước đó. Một đơn hàng bán có thể tạo ra một hoặc nhiều hóa đơn. Liên kết này cho thấy đầy đủ luồng chứng từ. Thuộc tính này rất quan trọng để phân tích Order-to-Cash từ đầu đến cuối. Nhờ đó, bạn có thể mở rộng góc nhìn quy trình về các bước trước khâu lập hóa đơn, tìm mối liên hệ giữa vấn đề thanh toán và nguyên nhân tiềm ẩn trong khâu tạo đơn hàng hoặc thực hiện đơn hàng. Chẳng hạn, thuộc tính này giúp tính tổng thời gian tạo hóa đơn, bắt đầu từ lúc đơn hàng được thực hiện. Vì sao điều này quan trọng Thuộc tính này liên kết hóa đơn với đơn hàng bán ban đầu, giúp bạn xem toàn bộ quy trình Order-to-Cash thay vì chỉ tập trung vào khâu thanh toán. Lấy dữ liệu ở đâu Bảng SAP: VBRP (dữ liệu mặt hàng trong chứng từ thanh toán), trường: AUBEL Ví dụ 100001231000045610000789 | |||
| Thanh toán đúng hạn IsPaidOnTime | Giá trị đúng/sai cho biết hóa đơn được thanh toán vào hoặc trước ngày đến hạn hay không. | ||
| Mô tả Đây là thuộc tính được tính bằng cách so sánh ngày thanh toán thực tế với ngày đến hạn theo lịch. Giá trị là “true” nếu thanh toán đúng hạn và “false” nếu thanh toán trễ. Cờ này giúp tính toán và trực quan hóa KPI tỷ lệ thanh toán đúng hạn dễ dàng hơn. Bạn có thể lọc và phân nhóm hóa đơn để so sánh những hóa đơn thanh toán trễ với những hóa đơn thanh toán đúng hạn. Qua đó, bạn có thể tìm ra các yếu tố liên quan đến việc thanh toán trễ, như khách hàng, khu vực hoặc điều khoản thanh toán cụ thể. Vì sao điều này quan trọng Thuộc tính này giúp đo lường hiệu quả bằng cách đánh dấu rõ từng hóa đơn là “đúng hạn” hay “trễ hạn”, hỗ trợ trực tiếp KPI tỷ lệ thanh toán đúng hạn. Lấy dữ liệu ở đâu Đây là trường được tính toán. Logic so sánh dấu thời gian của hoạt động “Đã nhận thanh toán từ khách hàng” với giá trị trong thuộc tính “PaymentDueDate”. Ví dụ truefalse | |||
| Tiền tệ Currency | Mã tiền tệ của giá trị hóa đơn. | ||
| Mô tả Thuộc tính này cho biết đơn vị tiền tệ của các khoản tiền trên hóa đơn, chẳng hạn USD, EUR hoặc JPY. Đây là ngữ cảnh cần thiết để hiểu các giá trị tiền tệ. Với tổ chức hoạt động trên nhiều quốc gia, tiền tệ rất quan trọng để phân tích và báo cáo tài chính chính xác. Thuộc tính này cho phép quy đổi các khoản tiền về cùng một đơn vị báo cáo để tổng hợp dữ liệu, đồng thời so sánh hiệu quả lập hóa đơn giữa các khu vực sử dụng tiền tệ địa phương khác nhau. Vì sao điều này quan trọng Thuộc tính này cung cấp ngữ cảnh cần thiết cho mọi giá trị tiền tệ, giúp phân tích và báo cáo tài chính chính xác, nhất là khi vận hành ở nhiều quốc gia. Lấy dữ liệu ở đâu Bảng SAP: VBRK, Trường: WAERK Ví dụ USDEURGBP | |||
| Trạng thái thanh toán PaymentStatus | Trạng thái hiện tại của khoản thanh toán hóa đơn, chẳng hạn còn mở, đã thanh toán hoặc quá hạn. | ||
| Mô tả Trạng thái thanh toán cho biết nhanh hóa đơn đang ở giai đoạn nào trong quy trình thu hồi công nợ. Trong SAP, thông tin này không nằm trong một trường riêng mà được xác định bằng cách kiểm tra trạng thái tất toán của chứng từ kế toán tương ứng. Thuộc tính này cần thiết cho dashboard theo dõi tuổi nợ của hóa đơn chưa thanh toán. Thuộc tính giúp phân loại các hóa đơn chưa thanh toán theo trạng thái và thời gian quá hạn, để nhóm thu hồi công nợ ưu tiên xử lý hiệu quả. Theo dõi sự thay đổi trạng thái cũng giúp giám sát chính quy trình thu hồi công nợ. Vì sao điều này quan trọng Thuộc tính này cho biết rõ trạng thái thu hồi công nợ của từng hóa đơn, giúp quản lý khoản phải thu và ưu tiên các nỗ lực thu hồi. Lấy dữ liệu ở đâu Xác định bằng cách kiểm tra trạng thái tất toán của chứng từ kế toán (VBRK-BELNR) trong các bảng tài chính như BSID (khoản mục chưa tất toán) và BSAD (khoản mục đã tất toán). Ví dụ Chưa thanh toánĐã thanh toánQuá hạnĐã thanh toán một phần | |||
Các hoạt động trong quy trình Order-to-Cash: thanh toán và lập hóa đơn
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Đã ghi nhận và đối soát tiền | Đánh dấu thời điểm khoản thanh toán nhận từ khách hàng được khớp với hóa đơn chưa thanh toán và dùng để tất toán khoản mục đó trong sổ phụ phải thu. Hoạt động này hoàn tất giao dịch về mặt tài chính. | ||
| Vì sao điều này quan trọng Đo hiệu quả của quy trình ghi nhận khoản thanh toán. Chậm trễ ở bước này có thể khiến số dư tài khoản khách hàng không phản ánh đúng thực tế và tạo thêm việc không cần thiết cho nhóm thu hồi công nợ. Lấy dữ liệu ở đâu Sự kiện được ghi nhận qua ngày tất toán (BSEG-AUGDT) trên dòng mục của chứng từ kế toán của hóa đơn gốc. Trường này được điền khi chứng từ tất toán tất toán khoản mục đó. Thu thập Được lấy từ trường ngày tất toán (AUGDT) trong bảng BSEG/ACDOCA cho dòng mục của hóa đơn. Loại sự kiện explicit | |||
| Đã nhận thanh toán từ khách hàng | Hoạt động này đánh dấu khoản thanh toán từ khách hàng được hạch toán vào hệ thống tài chính. Ở bước này, khoản tiền có thể chưa được gán cho một hóa đơn cụ thể, nhưng đã được ghi nhận. | ||
| Vì sao điều này quan trọng Đây là cột mốc quan trọng để tính số ngày phải thu (DSO). Sự kiện cho biết tiền đã được nhận, dù việc đối soát có thể chưa hoàn tất. Lấy dữ liệu ở đâu Được lấy từ ngày hạch toán (BKPF-BUDAT) của chứng từ thanh toán từ khách hàng, thường là chứng từ loại 'DZ' trong bảng BKPF. Thu thập Sự kiện được xác định dựa trên việc tạo chứng từ thanh toán trong BKPF/BSEG. Loại sự kiện explicit | |||
| Hóa đơn đã đóng | Hoạt động này thể hiện trạng thái cuối cùng của hóa đơn đã được thanh toán thành công. Về chức năng, sự kiện này tương đương với 'Đã ghi nhận và đối soát tiền', cho biết quy trình của hóa đơn đã hoàn tất. | ||
| Vì sao điều này quan trọng Đây là sự kiện kết thúc chính của luồng xử lý thông thường. Đo tổng thời gian chu kỳ đến mốc này giúp bạn nắm toàn bộ vòng đời lập và xuất hóa đơn từ đầu đến cuối. Lấy dữ liệu ở đâu Được suy ra từ trạng thái của dòng mục khách hàng trong chứng từ kế toán. Khoản mục được xem là đã đóng hoặc đã tất toán khi các trường ngày tất toán (BSEG-AUGDT) và chứng từ tất toán (BSEG-AUGBL) có giá trị. Thu thập Được suy ra khi trường ngày tất toán (AUGDT) trong bảng BSEG/ACDOCA của dòng mục hóa đơn đã có giá trị. Loại sự kiện inferred | |||
| Hóa đơn được hạch toán vào kế toán | Đánh dấu chứng từ thanh toán đã được hạch toán thành công vào phân hệ kế toán tài chính. Đây là cột mốc quan trọng, khi hóa đơn trở thành khoản phải thu chính thức và các bút toán được ghi vào sổ cái. | ||
| Vì sao điều này quan trọng Hoạt động này xác nhận hóa đơn đã trở thành chứng từ tài chính hợp lệ. Thời gian từ lúc tạo đến lúc hạch toán là KPI quan trọng, cho thấy hiệu quả xử lý nội bộ. Lấy dữ liệu ở đâu Sự kiện được ghi nhận khi chứng từ kế toán tương ứng được tạo. Chứng từ thanh toán (VBRK-VBELN) được liên kết với chứng từ kế toán (BKPF-BELNR) qua VBRK-BELNR; ngày hạch toán là BKPF-BUDAT. Thu thập Được lấy từ ngày hạch toán (BUDAT) của chứng từ kế toán trong bảng BKPF liên kết với chứng từ thanh toán. Loại sự kiện explicit | |||
| Hóa đơn được tạo | Hoạt động này đánh dấu thời điểm chứng từ thanh toán được tạo trong hệ thống. Đây là sự kiện được ghi nhận rõ ràng khi người dùng chạy giao dịch như VF01 hoặc khi một tác vụ chạy nền tạo hóa đơn, làm phát sinh bản ghi mới trong bảng tiêu đề chứng từ thanh 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 lập hóa đơn. Phân tích khoảng thời gian từ khi hoàn tất đơn hàng đến hoạt động này rất quan trọng để đo thời gian chu kỳ lập hóa đơn và xác định các chậm trễ ban đầu trong quy trình. Lấy dữ liệu ở đâu Được ghi trong bảng VBRK của SAP S/4HANA (Chứng từ thanh toán: Dữ liệu tiêu đề) khi chứng từ được tạo. Ngày tạo (VBRK-ERDAT) và giờ tạo (VBRK-ERZET) là dấu thời gian. Thu thập Sự kiện được lấy từ dấu thời gian tạo bản ghi chứng từ thanh toán trong bảng VBRK. Loại sự kiện explicit | |||
| Đã gửi nhắc thanh toán | Đánh dấu việc gửi lời nhắc thanh toán hoặc thông báo đòi nợ cho khách hàng về hóa đơn quá hạn. Đây là sự kiện được ghi nhận rõ ràng khi quy trình nhắc nợ tự động chạy. | ||
| Vì sao điều này quan trọng Sự kiện này giúp phân tích hiệu quả của quy trình nhắc nợ. Bạn có thể xác định liệu lời nhắc có giúp khách hàng thanh toán nhanh hơn và cấp độ nhắc nợ nào có tác động lớn nhất. Lấy dữ liệu ở đâu Được ghi trong các bảng lịch sử nhắc nợ (MAHNV, MHND) khi chạy quy trình nhắc nợ (giao dịch F150) cho khoản mục chưa thanh toán của hóa đơn. Thu thập Được lấy từ ngày chạy thông báo nhắc nợ trong các bảng lịch sử nhắc nợ. Loại sự kiện explicit | |||
| Đã tạo giấy báo có | Hoạt động này đánh dấu việc tạo giấy báo có để điều chỉnh khoản tính thừa cho khách hàng hoặc ghi có cho hàng hóa bị trả lại. Giấy báo có thường liên kết với hóa đơn gốc. | ||
| Vì sao điều này quan trọng Sự kiện này cho thấy có điều chỉnh tài chính sau khi lập hóa đơn. Phân tích giấy báo có có thể giúp phát hiện lỗi định giá, vấn đề về sản phẩm hoặc nguyên nhân khác làm thất thoát doanh thu. Lấy dữ liệu ở đâu Được tạo rõ ràng dưới dạng chứng từ thanh toán mới trong VBRK, với loại chứng từ dành riêng cho giấy báo có, chẳng hạn 'G2'. Chứng từ thường tham chiếu đơn hàng hoặc hóa đơn gốc. Thu thập Được ghi nhận khi tạo chứng từ thanh toán loại giấy báo có trong VBRK. Loại sự kiện explicit | |||
| Đến hạn thanh toán | Đây là sự kiện được tính toán, thể hiện ngày hóa đơn đến hạn thanh toán theo điều khoản đã thỏa thuận. Sự kiện này không phát sinh từ giao dịch mà được suy ra từ dữ liệu hóa đơn. | ||
| Vì sao điều này quan trọng Mốc này là cơ sở quan trọng để đo tỷ lệ thanh toán đúng hạn và phân tích hành vi thanh toán của khách hàng. Nhờ đó, bạn có thể phân biệt khoản thanh toán đúng hạn với khoản quá hạn. Lấy dữ liệu ở đâu Được tính dựa trên ngày cơ sở thanh toán (BSEG-ZFBDT) và điều khoản thanh toán lưu trong dòng mục khách hàng của chứng từ kế toán. Thu thập Được tính bằng cách cộng số ngày theo điều khoản thanh toán vào ngày cơ sở thanh toán trong dòng mục của chứng từ kế toán (BSEG). Loại sự kiện calculated | |||
| Hóa đơn bị chặn hạch toán | Sự kiện này xảy ra khi hóa đơn được tạo nhưng tự động bị chặn, không cho hạch toán vào kế toán tài chính vì nhiều lý do, chẳng hạn như kiểm tra tín dụng hoặc dữ liệu không nhất quán. Trạng thái này được suy ra từ trường trạng thái hạch toán trên chứng từ thanh toán. | ||
| Vì sao điều này quan trọng Sự kiện này giúp phát hiện điểm nghẽn khi hóa đơn đã được tạo nhưng chưa được chuyển sang bộ phận tài chính, làm chậm toàn bộ chu kỳ thu tiền. Đây cũng là dấu hiệu quan trọng cho thấy có thể có vấn đề về chất lượng dữ liệu hoặc quản lý tín dụng. Lấy dữ liệu ở đâu Trạng thái được suy ra từ trường trạng thái hạch toán trong bảng tiêu đề chứng từ thanh toán (VBRK-RFBSK). Trạng thái như 'A' (Chứng từ thanh toán bị chặn, không chuyển sang FI) cho biết chứng từ đang bị chặn. Thu thập Được suy ra bằng cách kiểm tra giá trị của trường trạng thái hạch toán (VBRK-RFBSK) ngay sau khi hóa đơn được tạo. Loại sự kiện inferred | |||
| Hóa đơn bị hủy | Sự kiện xảy ra khi một hóa đơn đã tạo trước đó bị hủy, thường bằng cách tạo chứng từ hủy tương ứng. Thao tác này đảo ngược hóa đơn gốc và ảnh hưởng kế toán của hóa đơn. | ||
| Vì sao điều này quan trọng Sự kiện này cho thấy có việc làm lại, sửa lỗi hoặc sai sót khi lập hóa đơn. Tỷ lệ hủy cao thường là dấu hiệu của vấn đề đáng kể ở các bước trước đó, như nhập đơn hàng hoặc cấu hình lập hóa đơn. Lấy dữ liệu ở đâu Được ghi nhận khi chứng từ thanh toán hủy được tạo, chẳng hạn chứng từ loại 'S1'. Chứng từ mới trong VBRK tham chiếu số hóa đơn gốc tại trường VBRK-SFAKN. Thu thập Sự kiện được lấy từ ngày tạo chứng từ hủy trong VBRK có tham chiếu đến hóa đơn gốc. Loại sự kiện explicit | |||
| Hóa đơn được gửi cho khách hàng | Hoạt động này đánh dấu thời điểm hóa đơn được gửi cho khách hàng, chẳng hạn qua bản in, email hoặc EDI. Cách ghi nhận sự kiện phụ thuộc vào cấu hình quản lý đầu ra trong SAP. | ||
| Vì sao điều này quan trọng Đây là thời điểm bắt đầu tính hạn thanh toán theo góc nhìn của khách hàng. Gửi hóa đơn chậm ảnh hưởng trực tiếp đến số ngày phải thu (DSO) và dòng tiền. Lấy dữ liệu ở đâu Sự kiện có thể được ghi rõ trong các bảng kiểm soát đầu ra, chẳng hạn NAST với các phương thức cũ hoặc bảng tương đương trong S/4HANA. Nếu không được ghi riêng, sự kiện thường được suy ra là xảy ra cùng lúc với 'Hóa đơn được hạch toán vào kế toán'. Thu thập Kiểm tra nhật ký xử lý trong các bảng quản lý đầu ra để tìm dấu thời gian gắn với loại đầu ra của hóa đơn. Loại sự kiện explicit | |||
| Khách hàng mở tranh chấp | Hoạt động này xảy ra khi khách hàng khiếu nại về hóa đơn và khiếu nại được ghi nhận chính thức trong hệ thống. Để ghi nhận sự kiện này, cần sử dụng phân hệ SAP Dispute Management. | ||
| Vì sao điều này quan trọng Sự kiện này cho thấy các vấn đề về độ chính xác của hóa đơn, chất lượng sản phẩm hoặc việc cung cấp dịch vụ có thể làm chậm thanh toán. Phân tích lý do tranh chấp giúp xử lý nguyên nhân gốc rễ và cải thiện mức độ hài lòng của khách hàng. Lấy dữ liệu ở đâu Được ghi nhận khi hồ sơ tranh chấp được tạo trong các bảng Dispute Management, chẳng hạn UDM_CASE, rồi liên kết với dòng mục của chứng từ kế toán. Thu thập Được lấy từ dấu thời gian tạo hồ sơ tranh chấp liên kết với hóa đơn. Loại sự kiện explicit | |||
| Phát hiện việc phải làm lại khi lập hóa đơn | Đây là sự kiện được tính toán để xác định vòng lặp làm lại, trong đó hóa đơn bị hủy rồi được tạo lại cho cùng một đơn hàng. Sự kiện này không tương ứng với một giao dịch riêng lẻ mà được suy ra từ một chuỗi sự kiện. | ||
| Vì sao điều này quan trọng Sự kiện này hỗ trợ trực tiếp cho KPI tỷ lệ phải làm lại khi lập hóa đơn bằng cách đếm số lần cần điều chỉnh. Nhờ đó, bạn có thể xác định điểm kém hiệu quả và đo chi phí do chất lượng quy trình lập hóa đơn chưa đạt yêu cầu. Lấy dữ liệu ở đâu Mẫu này được tính bằng cách tìm sự kiện 'Hóa đơn bị hủy' theo sau bởi sự kiện 'Hóa đơn được tạo' mới, trong đó cả hai cùng liên kết về một chứng từ nguồn, chẳng hạn số đơn hàng. Thu thập Được suy ra bằng cách phát hiện chuỗi sự kiện 'Hóa đơn bị hủy' rồi đến 'Hóa đơn được tạo' cho cùng một mã tham chiếu đơn hàng. Loại sự kiện calculated | |||
Hướng dẫn trích xuất dữ liệu
Các bước
- Điều kiện tiên quyết: Đảm bảo bạn có tài khoản người dùng SAP S/4HANA với quyền cần thiết để truy vấn các CDS view (Core Data Services). Cụ thể, bạn cần quyền đọc các view như I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase và I_DunningHistory.
- Mở công cụ trích xuất dữ liệu: Đăng nhập vào hệ thống SAP S/4HANA. Bạn có thể dùng nhiều công cụ để chạy truy vấn SQL trên CDS view, chẳng hạn SAP HANA Studio, DBeaver kết nối qua SAP HANA client hoặc plugin SAP Analysis for Microsoft Excel. Trong hướng dẫn này, chúng tôi giả định bạn dùng một ứng dụng SQL client thông dụng.
- Xác định thông số hệ thống: Trước khi chạy truy vấn, hãy xác định Company Code và khoảng ngày cần phân tích. Nên bắt đầu với phạm vi nhỏ, chẳng hạn dữ liệu trong 3 đến 6 tháng gần nhất, để thời gian chạy truy vấn ở mức hợp lý.
- Chuẩn bị truy vấn SQL: Sao chép toàn bộ truy vấn SQL trong phần 'query' của tài liệu này vào SQL client bạn chọn.
- Điền các giá trị thay thế: Sửa các giá trị giữ chỗ trong truy vấn. Thay
'YYYY-MM-DD'bằng ngày bắt đầu và ngày kết thúc mong muốn. Thay'XXXX'bằng Company Code cần lấy dữ liệu. Bạn cũng có thể cần điều chỉnh giá trị giữ chỗ cho loại chứng từ ghi có, chẳng hạn'G2', tùy theo cấu hình hệ thống. - Chạy truy vấn: Chạy truy vấn SQL đã sửa trên cơ sở dữ liệu SAP S/4HANA. Thời gian chạy tùy thuộc vào lượng dữ liệu trong khoảng ngày đã chọn.
- Kiểm tra kết quả: Khi truy vấn chạy xong, hãy xem kết quả. Dữ liệu trả về phải là một bảng phẳng, mỗi hàng tương ứng với một hoạt động trong quy trình lập hóa đơn. Đây là nhật ký sự kiện của bạn.
- Chuyển đổi dữ liệu (nếu cần): Truy vấn được thiết kế để tạo nhật ký sự kiện theo định dạng gọn, dễ dùng. Tuy vậy, hãy kiểm tra định dạng dấu thời gian để đảm bảo tương thích với công cụ process mining. Truy vấn dùng
ABAP_SYSTEM_UTCL_TO_TIMESTAMPđể chuyển sang dấu thời gian UTC tiêu chuẩn, thường tương thích với nhiều công cụ. - Xuất nhật ký sự kiện: Xuất toàn bộ kết quả từ SQL client thành tệp CSV. Đảm bảo tệp dùng mã hóa UTF-8 để tránh lỗi ký tự.
- Tải lên ProcessMind: Tải tệp CSV đã tạo lên nền tảng ProcessMind. Ánh xạ các cột trong tệp, như InvoiceNumber, ActivityName và EventTime, với các trường tương ứng trong công cụ.
Cấu hình
- Khoảng ngày: Đặt ngày bắt đầu và ngày kết thúc trong mệnh đề
WHEREcủa Common Table Expression (CTE) đầu tiên. Với lần phân tích đầu tiên, nên chọn khoảng 3 đến 6 tháng để cân bằng lượng dữ liệu và hiệu năng. Bộ lọc áp dụng choBillingDocumentDate. - Company Code: Lọc theo một hoặc nhiều giá trị
CompanyCodeđể chỉ trích xuất dữ liệu của các pháp nhân liên quan. Đây là bộ lọc quan trọng để kiểm soát phạm vi dữ liệu. - Loại chứng từ: Truy vấn có logic nhận diện chứng từ ghi có dựa trên
BillingDocumentType. Bạn cần cấu hình giá trị giữ chỗ, chẳng hạn('G2', 'CR'), bằng các loại chứng từ ghi có mà tổ chức đang sử dụng. - Điều kiện tiên quyết: Bạn phải có quyền truy cập các CDS view bên dưới. Đội ngũ bảo mật SAP cần cấp các vai trò và quyền phù hợp. Ngoài ra, để lấy các hoạt động như 'Customer Dispute Opened' hoặc 'Payment Reminder Issued', hệ thống phải đang sử dụng SAP Dispute Management và SAP Financials Dunning.
- Hiệu năng: Truy vấn dùng nhiều phép nối và hợp nhất. Với tập dữ liệu rất lớn, chẳng hạn dữ liệu trong vài năm, hãy cân nhắc chạy vào giờ thấp điểm hoặc thêm bộ lọc chặt hơn để giới hạn dữ liệu lấy ban đầu.
Truy vấn mẫu sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Các bước
- Xác nhận bạn có quyền chỉ đọc trực tiếp vào schema SAP HANA chứa các bảng lập hóa đơn và tài chính liên quan. Nhận tên schema, thông tin kết nối, khoảng ngày được phép, phạm vi Company Code, loại chứng từ lập hóa đơn và mọi bộ lọc khách hàng hoặc khu vực từ người quản lý hệ thống. Chỉ thay các giá trị giữ chỗ về kết nối và bộ lọc trong truy vấn.
- Xác nhận các nguồn dữ liệu SAP S/4HANA liên quan và cách ánh xạ trường trong hệ thống đích. Truy vấn dùng VBRK và VBRP cho dữ liệu lập hóa đơn, đồng thời cần cấu hình nguồn cho kế toán, quản lý đầu ra, quản lý tranh chấp, nhắc nợ, thanh toán đến, đối trừ và quan hệ giữa chứng từ. Chỉ thay các giá trị giữ chỗ trong ngoặc vuông cho nguồn và trường sau khi đối chiếu với từ điển dữ liệu của hệ thống.
- Cấu hình khoảng trích xuất với thời điểm bắt đầu được tính vào và thời điểm kết thúc không được tính vào. Lần chạy đầu tiên nên lấy dữ liệu trong 3 đến 6 tháng. Giới hạn theo Company Code và, khi phù hợp, theo loại lập hóa đơn để kiểm soát khối lượng và tránh trộn các quy trình không liên quan.
- Chạy truy vấn bằng tài khoản cơ sở dữ liệu HANA chỉ có quyền đọc. Truy vấn tạo một hàng sự kiện cho mỗi hoạt động được trích xuất rõ ràng. Truy vấn không dựa vào ProcessMind để suy luận sự kiện. Các hoạt động được tính toán, gồm Payment Due Date Reached và Billing Rework Identified, được tạo bằng logic SQL và trả về dưới dạng các hàng.
- Kiểm tra schema kết quả. Nhật ký sự kiện phải có InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region và EndTime. Xác nhận InvoiceNumber, ActivityName và EventTime có giá trị ở mọi hàng.
- Kiểm tra ý nghĩa sự kiện và mối liên hệ giữa chúng. Đối chiếu các hàng Invoice Generated với dữ liệu tạo tiêu đề hóa đơn, Invoice Posted To Accounting với trạng thái ghi sổ kế toán, Invoice Sent To Customer với bản ghi đầu ra, các hàng thanh toán với chứng từ kế toán và các hàng đối trừ với khoản mục hóa đơn đã được đối trừ. Rà soát mọi phần phụ thuộc vào giá trị giữ chỗ trước khi dùng trong môi trường thực tế.
- Chuẩn hóa kết quả cho ProcessMind. Giữ một hàng cho mỗi sự kiện, dùng kiểu dấu thời gian và múi giờ nhất quán, giữ InvoiceNumber ở dạng văn bản để không mất số 0 ở đầu, đồng thời đảm bảo giá trị ActivityName khớp chính xác với tên hoạt động yêu cầu. Sắp xếp theo InvoiceNumber và EventTime; nếu nhiều sự kiện có cùng dấu thời gian, hãy thêm tiêu chí sắp xếp phụ ổn định.
- Xuất kết quả thành CSV mã hóa UTF-8 hoặc định dạng bảng khác được ProcessMind hỗ trợ. Ánh xạ InvoiceNumber làm mã định danh trường hợp, ActivityName làm cột hoạt động và EventTime làm dấu thời gian sự kiện. Thêm các thuộc tính được khuyến nghị nếu có, sau đó tải tệp lên bằng quy trình nhập ProcessMind đã cấu hình và kiểm tra lần cuối số hàng cùng số lượng từng hoạt động.
Cấu hình
- Khoảng ngày: Bắt đầu với dữ liệu trong 3 đến 6 tháng. Dùng thời điểm bắt đầu được tính vào và thời điểm kết thúc không được tính vào để tránh trùng sự kiện giữa các lần trích xuất tăng dần.
- Mã định danh trường hợp: Dùng InvoiceNumber trong tiêu đề chứng từ lập hóa đơn. Giữ giá trị ở dạng chuỗi vì số chứng từ SAP có thể có số 0 ở đầu.
- Hoạt động bắt buộc: Kết quả trích xuất phải có hàng riêng cho Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created và Billing Rework Identified.
- Bộ lọc: Chỉ áp dụng bộ lọc Company Code, loại chứng từ lập hóa đơn, tổ chức bán hàng, khách hàng, khu vực và ngày sau khi xác nhận các trường tương ứng cùng phạm vi nghiệp vụ trong hệ thống đích. Không mặc định rằng mọi loại chứng từ lập hóa đơn đều theo cùng một quy trình kế toán hoặc quản lý đầu ra.
- Cấu hình nguồn: VBRK và VBRP là nguồn dữ liệu lập hóa đơn chính. Cần cấu hình nguồn kế toán, đầu ra, tranh chấp, nhắc nợ, thanh toán, đối trừ và luồng chứng từ theo phiên bản SAP S/4HANA đã triển khai cùng các mô-đun được bật. Thay các tham chiếu nguồn trong ngoặc vuông bằng đối tượng và trường đã được xác thực.
- Sự kiện được tính toán: Payment Due Date Reached được xác định từ điều khoản thanh toán và dữ liệu ngày đến hạn. Billing Rework Identified được xác định từ các mẫu hủy hóa đơn rồi tạo hóa đơn mới. Đây là các hàng sự kiện do SQL tạo, không phải bản ghi giao dịch gốc.
- Hiệu năng: Đưa bộ lọc ngày, Company Code, loại lập hóa đơn và số chứng từ vào từng truy vấn nguồn. Chỉ chọn các cột cần thiết, tránh nối không giới hạn với các bảng kế toán lớn, chia dữ liệu theo tháng hoặc tuần và dùng execution plan của cơ sở dữ liệu để tìm các phép nối tốn tài nguyên.
- Trích xuất tăng dần: Dùng mốc thời gian ổn định dựa trên thời điểm tạo hoặc ghi sổ ở nguồn. Xử lý lại một khoảng thời gian chồng lấn nhỏ để lấy các bản ghi đầu ra, thanh toán, tranh chấp và đối trừ đến muộn, sau đó loại trùng theo InvoiceNumber, ActivityName, EventTime cùng khóa chứng từ nguồn liên quan.
- Quyền truy cập: Tài khoản trích xuất cần có quyền đọc các đối tượng và trường trong schema HANA đã chọn. Xác nhận chính sách bảo mật của tổ chức cho phép truy cập cơ sở dữ liệu trực tiếp và đáp ứng các yêu cầu xử lý dữ liệu cá nhân hoặc dữ liệu khách hàng.
- Điều kiện nghiệp vụ: Chỉ có dữ liệu quản lý đầu ra, tích hợp kế toán, quản lý tranh chấp, nhắc nợ, thanh toán đến và đối trừ nếu các chức năng này đã được cấu hình và sử dụng trong hệ thống. Nếu thiếu mô-đun hoặc bản ghi nguồn, hoạt động tương ứng sẽ không có dữ liệu, chứ không được suy luận.
- Múi giờ: Chuẩn hóa dấu thời gian theo múi giờ ProcessMind yêu cầu. Ghi rõ dấu thời gian nguồn được lưu theo UTC, giờ địa phương của hệ thống hay múi giờ khác đã cấu hình.
Truy vấn mẫu sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Sẵn sàng bắt đầu?
Dùng mẫu này để chuẩn bị dữ liệu nhanh hơn và bắt đầu cải tiến quy trình Order to Cash - Billing & Invoicing. Chuyển dữ liệu SAP S/4H4ANA thành thông tin hữu ích ngay hôm nay.
Cải tiến quy trình lập hóa đơn Order to Cash để dòng tiền về nhanh hơn 30%
Loại bỏ những khâu kém hiệu quả và rút ngắn 30% thời gian lập hóa đơn ngay hôm nay.
Không cần thẻ tín dụng. Bắt đầu chỉ trong vài phút.