Mẫu dữ liệu xử lý thanh toán của bạn

ACI Worldwide
Mẫu dữ liệu xử lý thanh toán của bạn

Mẫu dữ liệu xử lý thanh toán của bạn

Mẫu này hướng dẫn bạn chuẩn bị dữ liệu xử lý thanh toán để phân tích. Mẫu nêu rõ các thuộc tính cần thu thập, hoạt động quan trọng cần theo dõi và cách trích xuất thông tin từ hệ thống. Làm theo các đề xuất này sẽ giúp bạn xây dựng nền tảng dữ liệu vững chắc để tìm ra điểm kém hiệu quả và tối ưu vận hành tài chính.
  • 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ừ ACI Worldwide
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính xử lý thanh toán

Đây là các trường dữ liệu nên có trong nhật ký sự kiện để phân tích quy trình xử lý thanh toán.
3 Bắt buộc 9 Nên có 7 Không bắt buộc
Tên Mô tả
Dấu thời gian sự kiện
EventTimestamp
Ngày và giờ cụ thể khi hoạt động diễn ra.
Mô tả

Thuộc tính này ghi lại chính xác thời điểm sự kiện xảy ra trong môi trường ACI. Dữ liệu này được dùng để tính mọi chỉ số thời gian, gồm thời gian chu kỳ, thời gian phê duyệt và tốc độ xử lý. Nên dùng độ chính xác cao đến mili giây để sắp xếp đúng thứ tự các bước tự động diễn ra nhanh.

Vì sao điều này quan trọng

Cần thiết để sắp xếp sự kiện và tính thời lượng hiệu suất.

Lấy dữ liệu ở đâu

Kiểm tra cột 'Ngày tạo' hoặc 'Ngày cập nhật' trong lịch sử giao dịch hay bảng nhật ký kiểm tra.

Ví dụ
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
Payment Transaction ID
PaymentTransactionId
Mã định danh duy nhất của chỉ thị thanh toán cụ thể trong toàn hệ thống ACI.
Mô tả

Thuộc tính này là khóa chính cho phân tích process mining, dùng để liên kết mọi sự kiện của cùng một yêu cầu thanh toán. Trong các hệ thống ACI Worldwide như MTS hoặc UPP, đây là mã tham chiếu duy nhất được gán cho giao dịch khi nhập. Mã này giúp dựng lại toàn bộ hành trình thanh toán, từ yêu cầu ban đầu qua xác thực, phê duyệt đến quyết toán cuối cùng.

Vì sao điều này quan trọng

Đây là Case ID cơ bản cần có để nhóm các sự kiện riêng lẻ thành từng phiên bản quy trình.

Lấy dữ liệu ở đâu

Kiểm tra các bảng tiêu đề giao dịch. Trong nhật ký giao dịch chính, trường này thường có tên TRN_REF, REFERENCE_NUM hoặc UUID.

Ví dụ
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
Tên hoạt động
ActivityName
Bước cụ thể hoặc thay đổi trạng thái trong vòng đời thanh toán.
Mô tả

Thuộc tính này xác định nút sự kiện trên sơ đồ quy trình, chẳng hạn như 'Đã tạo yêu cầu thanh toán' hoặc 'Đã chuyển tiền'. Trong hệ thống ACI, thông tin này thường được lấy từ mã trạng thái, loại thao tác trong nhật ký kiểm tra hoặc thay đổi trạng thái workflow. Việc ánh xạ chính xác các trạng thái kỹ thuật sang hoạt động dễ hiểu với người dùng nghiệp vụ rất quan trọng để trực quan hóa có ý nghĩa.

Vì sao điều này quan trọng

Thuộc tính này xác định luồng quy trình và cần thiết để trực quan hóa trình tự vận hành.

Lấy dữ liệu ở đâu

Lấy từ mã trạng thái (ví dụ: 100=Tạo mới, 200=Đã xác thực) hoặc cột thao tác trong nhật ký kiểm tra.

Ví dụ
Đã tạo yêu cầu thanh toánĐã cấp quyền thanh toánThanh toán hoàn tấtThanh toán thất bại
Có làm lại
IsRework
Cờ cho biết khoản thanh toán có trải qua các hoạt động lặp lại hay không.
Mô tả

Cờ đúng/sai được tính trong quá trình xử lý dữ liệu. Cờ được đặt thành true nếu hoạt động như 'Đã xác thực chi tiết thanh toán' diễn ra nhiều lần hoặc phát hiện vòng lặp lỗi. Dữ liệu này dùng để tính KPI 'Tỷ lệ thanh toán phải làm lại'.

Vì sao điều này quan trọng

Nhanh chóng xác định các trường hợp kém hiệu quả mà không cần truy vấn quy trình phức tạp.

Lấy dữ liệu ở đâu

Được tính trong luồng dữ liệu bằng cách kiểm tra hoạt động trùng lặp trong từng trường hợp.

Ví dụ
truefalse
Đơn vị tiền tệ thanh toán
PaymentCurrency
Mã tiền tệ ISO của số tiền thanh toán.
Mô tả

Cho biết đơn vị tiền tệ của PaymentAmount (ví dụ: USD, EUR, GBP). Thông tin này cần thiết để chuẩn hóa dữ liệu trên dashboard tổng hợp khối lượng giao dịch từ nhiều khu vực. Nhờ đó, bạn có thể hiểu rõ hơn những phức tạp của thanh toán xuyên biên giới.

Vì sao điều này quan trọng

Cần có để hiểu chính xác số tiền thanh toán.

Lấy dữ liệu ở đâu

Bảng chi tiết giao dịch, thường có các trường như CCY, CURRENCY_CODE hoặc ISO_CODE.

Ví dụ
USDEURGBPJPY
Kênh xử lý
ProcessingChannel
Kênh dùng để khởi tạo thanh toán.
Mô tả

Cho biết điểm tiếp nhận khoản thanh toán, chẳng hạn như ứng dụng di động, cổng web, API hoặc tải tệp lên. Thuộc tính này hỗ trợ 'Phân tích biến thể quy trình thanh toán', giúp xác định kênh nào dễ phát sinh lỗi hoặc chậm trễ hơn.

Vì sao điều này quan trọng

Phân nhóm hiệu suất theo phương thức nhập.

Lấy dữ liệu ở đâu

Tiêu đề giao dịch, thường có các cột CHANNEL, SOURCE_TYPE hoặc INPUT_METHOD.

Ví dụ
SWIFTNgân hàng trực tuyếnỨng dụng di độngTải tệp lên
Loại thanh toán
PaymentType
Phân loại phương thức thanh toán.
Mô tả

Phân loại khoản thanh toán (ví dụ: chuyển khoản điện tử, ACH, SEPA, RTGS). Mỗi loại thường có SLA và luồng quy trình rất khác nhau. Đây là tiêu chí chính để lọc dashboard 'Thời gian chu kỳ thanh toán từ đầu đến cuối'.

Vì sao điều này quan trọng

Cần thiết để phân biệt luồng thanh toán tốc độ cao với luồng xử lý theo lô.

Lấy dữ liệu ở đâu

Tiêu đề giao dịch, thường có các trường PMT_TYPE, INSTRUMENT_TYPE hoặc SERVICE_ID.

Ví dụ
Chuyển khoản trong nướcChuyển khoản quốc tếACH ghi cóThanh toán tức thời
Mã lỗi
ErrorCode
Mã được tạo khi thanh toán thất bại hoặc cần sửa.
Mô tả

Ghi nhận nguyên nhân cụ thể của sự kiện 'Thanh toán thất bại' hoặc 'Phát hiện lỗi thanh toán'. Nhóm theo thuộc tính này trên dashboard 'Phân tích thanh toán thất bại và làm lại' giúp doanh nghiệp xác định nguyên nhân gốc phổ biến nhất, chẳng hạn như 'Không đủ tiền' hoặc 'Tài khoản không hợp lệ'.

Vì sao điều này quan trọng

Cần thiết để phân tích nguyên nhân gốc của lỗi quy trình.

Lấy dữ liệu ở đâu

Nhật ký lỗi hoặc cột lý do trạng thái, thường có tên REASON_CODE hoặc RETURN_CODE.

Ví dụ
R01AM04BE05TECH_ERR_001
Ngày đến hạn thanh toán
PaymentDueDate
Ngày khoản thanh toán phải được quyết toán để được xem là đúng hạn.
Mô tả

Lưu ngày thực hiện theo hợp đồng hoặc theo yêu cầu. Ngày này được so sánh với ngày quyết toán thực tế để tính KPI 'Tỷ lệ thanh toán đúng hạn' và hỗ trợ dashboard 'Tuân thủ ngày đến hạn thanh toán'.

Vì sao điều này quan trọng

Mốc chuẩn để đo lường việc tuân thủ SLA và hiệu suất thanh toán đúng hạn.

Lấy dữ liệu ở đâu

Chỉ thị giao dịch, thường có các trường VALUE_DATE, EXECUTION_DATE hoặc DUE_DATE.

Ví dụ
2023-11-012023-11-05
Người dùng thực hiện sự kiện
EventUser
ID người dùng hoặc tác nhân hệ thống chịu trách nhiệm cho hoạt động.
Mô tả

Ghi nhận ai thực hiện thao tác, có thể là người dùng (ví dụ: phê duyệt) hoặc tài khoản hệ thống (ví dụ: quyết toán tự động). Thuộc tính này rất quan trọng khi 'Phân tích điểm nghẽn' để xác định người dùng hoặc hàng đợi nào đang quá tải.

Vì sao điều này quan trọng

Hỗ trợ phân tích tài nguyên và kiểm tra việc phân tách nhiệm vụ.

Lấy dữ liệu ở đâu

Nhật ký kiểm tra hoặc cột 'UpdatedBy' trong bảng giao dịch.

Ví dụ
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
Phòng ban
Department
Phòng ban nội bộ chịu trách nhiệm cho hoạt động hiện tại.
Mô tả

Ánh xạ EventUser hoặc hàng đợi vào đơn vị tổ chức rộng hơn (ví dụ: 'Vận hành thanh toán', 'Tuân thủ', 'Ngân quỹ'). Nhờ đó, trong 'Phân tích điểm nghẽn theo hoạt động', bạn có thể xác định nhóm nào đang làm chậm quy trình.

Vì sao điều này quan trọng

Tổng hợp hiệu suất theo chức năng kinh doanh.

Lấy dữ liệu ở đâu

Lấy từ bảng người dùng hoặc sơ đồ phân cấp tổ chức.

Ví dụ
Vận hànhComplianceNgân quỹHỗ trợ CNTT
Số tiền thanh toán
PaymentAmount
Giá trị tiền tệ của giao dịch thanh toán.
Mô tả

Cho biết giá trị tài chính được chuyển. Đây là trường thông tin quan trọng để phân tích 'Thông lượng thanh toán' và xác định thứ tự ưu tiên xử lý điểm nghẽn. Khoản thanh toán giá trị cao thường cần quy trình phê duyệt chặt chẽ hơn (phân tích biến thể) so với luồng tự động giá trị thấp.

Vì sao điều này quan trọng

Cho phép phân nhóm theo giá trị và tính tổng khối lượng đã xử lý.

Lấy dữ liệu ở đâu

Bảng chi tiết giao dịch, thường có các trường như AMT, TRANS_AMOUNT hoặc PRINCIPAL_AMOUNT.

Ví dụ
1500.00250000.5050.001000000.00
Hệ thống nguồn
SourceSystem
Tên hệ thống nơi dữ liệu sự kiện được tạo ra.
Mô tả

Xác định ứng dụng hoặc mô-đun cụ thể trong hệ sinh thái ACI Worldwide (ví dụ: ACI MTS, ACI UPF) hoặc hệ thống bên ngoài tham gia vào luồng. Thông tin này đặc biệt quan trọng khi kết hợp dữ liệu từ nhiều sổ cái hoặc khi khoản thanh toán đi qua các đơn vị bù trừ bên ngoài.

Vì sao điều này quan trọng

Cho biết dữ liệu được trích xuất từ đâu, hữu ích khi kiểm tra nguồn gốc dữ liệu.

Lấy dữ liệu ở đâu

Được gán cố định khi trích xuất hoặc lấy từ cột SystemID nếu có nhiều phiên bản hệ thống.

Ví dụ
ACI MTSACI UPPSAP GLSwift Gateway
ID đối soát
ReconciliationId
Mã định danh liên kết khoản thanh toán với sổ cái tổng hợp hoặc hồ sơ đối soát.
Mô tả

ID này được điền khi hoạt động 'Đã đối soát thanh toán' diễn ra. ID giúp đảm bảo khoản thanh toán trong công cụ xử lý khớp với bút toán trong hệ thống kế toán. Nếu khoản thanh toán đã quyết toán nhưng thiếu ID này, có thể đã xảy ra lỗi đối soát.

Vì sao điều này quan trọng

Cần thiết cho dashboard 'Hiệu quả đối soát thanh toán'.

Lấy dữ liệu ở đâu

Bảng đối soát hoặc các trường cụ thể như RECON_REF hay GL_REF.

Ví dụ
REC-9921GL-Entry-2023-11
Khu vực khởi tạo
OriginatingRegion
Khu vực địa lý nơi yêu cầu thanh toán được khởi tạo.
Mô tả

Cho biết vị trí thực tế hoặc theo hệ thống của người yêu cầu. Thuộc tính này hữu ích cho 'Phân tích biến thể quy trình thanh toán', giúp xác định khu vực nào đi theo luồng không chuẩn hoặc có tỷ lệ bị từ chối cao hơn.

Vì sao điều này quan trọng

Cung cấp bối cảnh địa lý để phân tích hiệu suất quy trình.

Lấy dữ liệu ở đâu

Tiêu đề giao dịch, thường được lấy từ mã chi nhánh hoặc mã quốc gia.

Ví dụ
Bắc MỹChâu Âu, Trung Đông và châu PhiChâu Á - Thái Bình Dương
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian cho biết lần gần nhất bản ghi được trích xuất hoặc cập nhật trong mô hình dữ liệu.
Mô tả

Theo dõi mức độ mới của dữ liệu dùng trong phân tích. Đây không phải thời điểm xảy ra sự kiện trong quy trình, mà là thời điểm kỹ thuật khi dữ liệu được nạp. Nhờ đó, chuyên viên phân tích biết dữ liệu đang xem là dữ liệu thời gian thực hay ảnh chụp dữ liệu lịch sử.

Vì sao điều này quan trọng

Giúp xác định dữ liệu còn mới hay không và phát hiện dữ liệu cũ trên dashboard.

Lấy dữ liệu ở đâu

Thời gian hệ thống tại thời điểm chạy tập lệnh ETL.

Ví dụ
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
Tên người thụ hưởng
BeneficiaryName
Tên cá nhân hoặc tổ chức nhận khoản thanh toán.
Mô tả

Xác định bên đối tác trong giao dịch. Phân tích trường này giúp tìm nhà cung cấp hoặc khách hàng cụ thể có tỷ lệ làm lại cao hay thường bị chậm trễ, qua đó hỗ trợ 'Phân tích thanh toán thất bại và làm lại'.

Vì sao điều này quan trọng

Xác định bên nhận thanh toán, hữu ích cho phân tích lấy khách hàng làm trọng tâm.

Lấy dữ liệu ở đâu

Các dòng chi tiết thanh toán, thường có các trường CREDITOR_NAME, BENE_NAME hoặc PAYEE.

Ví dụ
Acme CorpGlobal Supplies LtdJohn Smith
Thanh toán trễ
IsPaymentLate
Cờ cho biết khoản thanh toán được quyết toán sau ngày đến hạn hay không.
Mô tả

Cờ đúng/sai so sánh ngày quyết toán thực tế với PaymentDueDate. Cờ này dùng để tính các chỉ số trên dashboard 'Tuân thủ ngày đến hạn thanh toán' và xác định trường hợp vi phạm SLA.

Vì sao điều này quan trọng

Đơn giản hóa việc báo cáo tuân thủ.

Lấy dữ liệu ở đâu

Được tính như sau: SettlementDate > PaymentDueDate.

Ví dụ
truefalse
Thời gian chu kỳ phê duyệt
ApprovalCycleTime
Thời gian dành cho giai đoạn phê duyệt.
Mô tả

Tính khoảng thời gian từ 'Đã gửi thanh toán để phê duyệt' đến 'Đã phê duyệt thanh toán' (hoặc bị từ chối). Chỉ số này được dùng trên dashboard 'Phân tích thời gian chu kỳ phê duyệt thanh toán', giúp làm rõ các chậm trễ trong bước cần con người ra quyết định.

Vì sao điều này quan trọng

Tách riêng phần quy trình phụ thuộc vào con người.

Lấy dữ liệu ở đâu

Được tính như sau: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval).

Ví dụ
4 giờ15 phút
Bắt buộc Nên có Không bắt buộc

Hoạt động xử lý thanh toán

Đây là các bước và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá chính xác quy trình xử lý thanh toán.
6 Nên có 8 Không bắt buộc
Hoạt động Mô tả
Đã cấp quyền thanh toán
Thể hiện việc hệ thống cấp quyền thanh toán sau khi được con người phê duyệt, bằng cách xác minh nguồn tiền hoặc kiểm tra theo quy tắc chống gian lận. Đây có thể là mục ghi nhật ký rõ ràng hoặc được suy ra từ thay đổi trạng thái cho biết giao dịch đã sẵn sàng thực hiện.
Vì sao điều này quan trọng

Đây là điểm kiểm soát quan trọng trước khi có lệnh chuyển tiền. Chậm trễ ở giai đoạn này có thể cho thấy vấn đề về hiệu suất hệ thống hoặc các hệ thống con kiểm tra tuân thủ và gian lận.

Lấy dữ liệu ở đâu

Hãy tìm mục ghi nhật ký rõ ràng trong nhật ký xử lý hệ thống hoặc nhật ký bảo mật. Ngoài ra, có thể suy ra từ thay đổi trạng thái từ 'Đã phê duyệt' sang 'Đã cấp quyền thanh toán'.

Thu thập

Được công cụ xử lý thanh toán của hệ thống ghi nhận sau khi giao dịch vượt qua các bước kiểm tra nội bộ cuối cùng.

Loại sự kiện explicit
Đã chuyển tiền
Cho biết mạng thanh toán đã gửi xác nhận rằng tiền được trừ thành công khỏi tài khoản người trả. Thông tin này thường được ghi nhận từ thông điệp trạng thái gửi đến từ mạng.
Vì sao điều này quan trọng

Xác nhận mạng bên ngoài đã thực hiện thanh toán thành công. Đây là thời điểm bắt đầu giai đoạn hoàn tất thanh toán và là dữ liệu đầu vào quan trọng cho KPI 'Thời gian hoàn tất thanh toán trung bình'.

Lấy dữ liệu ở đâu

Đây là sự kiện rõ ràng được kích hoạt khi nhận thông điệp cập nhật trạng thái, chẳng hạn MT103 từ SWIFT hoặc xác nhận ACH, làm thay đổi bản ghi thanh toán.

Thu thập

Được ghi nhận khi nhận thông điệp xác nhận từ mạng thanh toán bù trừ.

Loại sự kiện explicit
Đã phê duyệt thanh toán
Đây là mốc quan trọng khi người dùng có thẩm quyền phê duyệt khoản thanh toán để giao dịch được chuyển sang bước thực hiện. Thông tin này thường được ghi nhận thành sự kiện rõ ràng khi người phê duyệt thao tác trên giao diện hệ thống.
Vì sao điều này quan trọng

Hoạt động này là một điểm kiểm soát quan trọng và thường trở thành điểm nghẽn đáng kể. Phân tích thời gian chờ trước bước này và thời lượng của chu kỳ phê duyệt giúp xác định cơ hội đẩy nhanh thanh toán.

Lấy dữ liệu ở đâu

Hãy tìm sự kiện được ghi rõ trong bảng nhật ký phê duyệt hoặc thay đổi trạng thái thành 'Đã phê duyệt' trong bảng giao dịch chính, gắn với thao tác và dấu thời gian của một người dùng cụ thể.

Thu thập

Được ghi nhận khi người dùng có thẩm quyền hoàn tất thao tác phê duyệt trong hệ thống.

Loại sự kiện explicit
Đã tạo yêu cầu thanh toán
Hoạt động này đánh dấu thời điểm khởi tạo giao dịch thanh toán mới trong hệ thống ACI Worldwide. Thông thường, đây là sự kiện được ghi nhận rõ ràng khi người dùng hoặc hệ thống nguồn gửi yêu cầu thanh toán, tạo một bản ghi giao dịch mới với mã định danh duy nhất.
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính của quy trình thanh toán. Phân tích thời gian từ hoạt động này đến khi hoàn tất giúp tính thời gian chu kỳ từ đầu đến cuối, một chỉ số thiết yếu để đo hiệu quả chung của quy trình.

Lấy dữ liệu ở đâu

Đây thường là sự kiện được ghi rõ trong bảng giao dịch chính hoặc nhật ký sự kiện riêng của ACI. Hãy tìm dấu thời gian tạo gắn với Payment Transaction ID.

Thu thập

Xác định qua bản ghi tạo giao dịch hoặc sự kiện 'Tạo' được ghi rõ trong nhật ký giao dịch.

Loại sự kiện explicit
Phát hiện lỗi thanh toán
Cho biết hệ thống đã phát hiện sự cố ở một giai đoạn nào đó của quá trình thanh toán, chẳng hạn như dữ liệu không hợp lệ hoặc cảnh báo tuân thủ. Sự kiện này thường được ghi rõ cùng mã lỗi liên quan.
Vì sao điều này quan trọng

Hoạt động này là điểm bắt đầu để phân tích mọi trường hợp làm lại và xử lý ngoại lệ. Đây là dữ liệu thiết yếu cho các dashboard 'Phân tích thanh toán thất bại và làm lại' và 'Thời gian xử lý lỗi'.

Lấy dữ liệu ở đâu

Tìm các mục ghi rõ trong bảng nhật ký lỗi hoặc trạng thái chuyển thành 'Lỗi' hay 'Cần chỉnh sửa' trong bảng giao dịch. Liên kết các sự kiện này với Payment Transaction ID.

Thu thập

Ghi nhận sự kiện cụ thể khi công cụ xác thực hoặc xử lý của hệ thống phát hiện lỗi.

Loại sự kiện explicit
Thanh toán hoàn tất
Đây là xác nhận cuối cùng rằng quy trình thanh toán đã hoàn tất và tiền đã được ghi có vào tài khoản người nhận, kết thúc giao dịch. Đây là sự kiện quan trọng, đánh dấu giao dịch đã hoàn tất thành công.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc thành công chính của quy trình. Sự kiện này được dùng để tính thời gian chu kỳ tổng thể và lượng giao dịch xử lý được, đồng thời là dữ liệu thiết yếu cho hầu hết dashboard theo dõi hiệu quả từ đầu đến cuối.

Lấy dữ liệu ở đâu

Thông thường, đây là sự kiện được ghi rõ khi nhận thông điệp xác nhận hoàn tất thanh toán cuối cùng từ mạng hoặc khi sổ cái nội bộ được cập nhật để ghi nhận giao dịch đã hoàn tất.

Thu thập

Ghi nhận khi nhận được tệp hoặc thông điệp quyết toán cuối cùng, sau đó cập nhật trạng thái thành 'Đã quyết toán'.

Loại sự kiện explicit
Đã đối soát thanh toán
Đây là bước kế toán cuối cùng, khi giao dịch thanh toán được ghi nhận trong ACI được đối chiếu với sao kê ngân hàng hoặc bút toán sổ cái. Sự kiện này có thể được ghi rõ trong mô-đun đối soát hoặc suy ra từ thay đổi trạng thái.
Vì sao điều này quan trọng

Hoạt động này đo lường hiệu quả của quy trình đối soát ở bộ phận hỗ trợ. Chậm trễ ở bước này có thể ảnh hưởng đến độ chính xác của báo cáo tài chính và khiến các khoản thanh toán chưa quyết toán bị bỏ sót.

Lấy dữ liệu ở đâu

Thông tin này có thể đến từ mô-đun đối soát riêng trong ACI hoặc hệ thống ERP bên ngoài. Có thể ghi nhận thông qua cập nhật trạng thái khoản thanh toán thành 'Đã đối soát'.

Thu thập

Suy ra từ cập nhật trạng thái cuối cùng thành 'Đã đối soát' hoặc từ dữ liệu đối soát được nối bằng Payment ID.

Loại sự kiện inferred
Đã gửi lệnh thanh toán
Đánh dấu thời điểm lệnh thanh toán được tạo và gửi đến mạng thanh toán bên ngoài như SWIFT, ACH hoặc SEPA. Hệ thống ACI ghi rõ lần chuyển giao này để phục vụ kiểm toán và theo dõi.
Vì sao điều này quan trọng

Với nhiều loại thanh toán, đây là 'thời điểm không thể quay lại'. Theo dõi mốc này giúp đo thời gian xử lý nội bộ trước khi các yếu tố bên ngoài bắt đầu ảnh hưởng.

Lấy dữ liệu ở đâu

Hầu như luôn có sự kiện được ghi rõ trong nhật ký giao dịch hoặc nhật ký thông điệp của ACI, thường kèm theo mã tham chiếu riêng của mạng thanh toán.

Thu thập

Một mục ghi nhật ký rõ ràng được tạo khi thông điệp thanh toán được gửi đến mạng bên ngoài.

Loại sự kiện explicit
Đã gửi thanh toán để phê duyệt
Cho biết khoản thanh toán đã qua bước xác thực ban đầu và được chuyển đi để xin phê duyệt cần thiết từ quản lý hoặc bộ phận tài chính. Thông tin này thường được ghi nhận qua thay đổi trạng thái trong quy trình làm việc thanh toán.
Vì sao điều này quan trọng

Đây là thời điểm bắt đầu quy trình con phê duyệt. Đo thời gian từ bước này đến 'Đã phê duyệt thanh toán' là việc cần thiết cho dashboard 'Phân tích thời gian chu kỳ phê duyệt thanh toán'.

Lấy dữ liệu ở đâu

Có thể xác định từ thay đổi trong trường trạng thái thanh toán của dữ liệu giao dịch, chẳng hạn khi trạng thái chuyển thành 'Chờ phê duyệt'.

Thu thập

Có thể suy ra từ thay đổi trạng thái thành 'Chờ phê duyệt' hoặc trạng thái tương tự, cùng với dấu thời gian tương ứng.

Loại sự kiện inferred
Đã từ chối thanh toán
Sự kiện này xảy ra khi người phê duyệt từ chối yêu cầu thanh toán, thường khiến giao dịch cần được chỉnh sửa và gửi lại. Đây là sự kiện được ghi nhận rõ ràng, làm gián đoạn tiến trình thanh toán và bắt đầu một vòng lặp làm lại.
Vì sao điều này quan trọng

Giúp xác định công việc phải làm lại và những điểm kém hiệu quả trong quy trình. Theo dõi tần suất từ chối giúp tìm ra vấn đề về chất lượng dữ liệu ban đầu hoặc chính sách gửi yêu cầu, hỗ trợ phân tích công việc phải làm lại.

Lấy dữ liệu ở đâu

Được ghi nhận thành sự kiện rõ ràng trong nhật ký phê duyệt hoặc qua thay đổi trạng thái thành 'Đã từ chối' trong bảng giao dịch. Sự kiện có thể bao gồm mã lý do từ chối.

Thu thập

Được ghi nhận khi người phê duyệt hoàn tất thao tác từ chối trong hệ thống.

Loại sự kiện explicit
Đã xác nhận thanh toán
Thể hiện việc hệ thống nội bộ xác nhận thanh toán đã được xử lý thành công và đã nhận được xác nhận. Đây thường là thời điểm kích hoạt thông báo cho người nhận hoặc các hệ thống nội bộ khác.
Vì sao điều này quan trọng

Mốc này rất quan trọng để đo lường việc thanh toán đúng hạn và tỷ lệ thanh toán đúng hạn. Mốc thời gian này cho biết rõ khi nào tổ chức xem khoản thanh toán là đã được thực hiện thành công.

Lấy dữ liệu ở đâu

Thông thường có thể suy ra từ việc trạng thái trong bảng giao dịch thanh toán chuyển thành 'Đã xác nhận' hoặc 'Đã hoàn tất' sau khi nhận xác nhận từ mạng bên ngoài.

Thu thập

Có thể suy ra từ thay đổi trạng thái thành 'Đã xác nhận' hoặc 'Đã xử lý'.

Loại sự kiện inferred
Đã xác thực thông tin thanh toán
Hoạt động này thể hiện việc hoàn tất các bước kiểm tra tự động hoặc thủ công để đảm bảo thông tin thanh toán, chẳng hạn như thông tin người nhận và mã ngân hàng, là chính xác. Thường có thể suy ra hoạt động này từ việc trạng thái giao dịch chuyển từ 'Mới' sang 'Đã xác thực' hoặc 'Chờ phê duyệt'.
Vì sao điều này quan trọng

Theo dõi hiệu quả của các bước xác thực dữ liệu ban đầu. Chậm trễ ở đây có thể tạo điểm nghẽn ở các bước tiếp theo và làm tăng khả năng xảy ra lỗi thanh toán về sau.

Lấy dữ liệu ở đâu

Có thể suy ra từ các trường thay đổi trạng thái trong bảng giao dịch thanh toán chính. So sánh dấu thời gian của trạng thái 'Đã tạo' với trạng thái tiếp theo như 'Đã xác thực'.

Thu thập

Có thể suy ra từ thay đổi trong trường trạng thái thanh toán, chẳng hạn từ 'Đã nhập' sang 'Đã xác thực'.

Loại sự kiện inferred
Đã xử lý lỗi thanh toán
Đánh dấu thời điểm người dùng sửa lỗi đã phát hiện trước đó và gửi lại khoản thanh toán để xử lý. Sự kiện này thường được suy ra khi trạng thái thanh toán chuyển từ trạng thái lỗi về trạng thái xử lý bình thường.
Vì sao điều này quan trọng

Hoạt động này khép lại vòng xử lý ngoại lệ. Khoảng thời gian từ 'Phát hiện lỗi thanh toán' đến sự kiện này là thời gian xử lý lỗi, một chỉ số quan trọng về hiệu quả vận hành.

Lấy dữ liệu ở đâu

Suy ra khi trạng thái chuyển khỏi 'Lỗi' sang trạng thái xử lý như 'Chờ phê duyệt' hoặc 'Đã xác thực'. Cũng có thể lấy từ nhật ký ghi rõ thao tác của người dùng.

Thu thập

Suy ra khi trạng thái chuyển khỏi trạng thái lỗi, cho biết lỗi đã được sửa.

Loại sự kiện inferred
Thanh toán thất bại
Trạng thái kết thúc cho biết không thể hoàn tất thanh toán do sự cố không thể khắc phục. Trạng thái này khác với lỗi có thể xử lý và xác nhận thanh toán đã thất bại hoàn toàn.
Vì sao điều này quan trọng

Theo dõi sự kiện kết thúc này rất quan trọng để tính tỷ lệ thanh toán thất bại tổng thể. Phân tích nguyên nhân thất bại giúp cải thiện chất lượng dữ liệu và quy tắc quy trình.

Lấy dữ liệu ở đâu

Suy ra từ trạng thái cuối cùng như 'Thất bại', 'Đã hủy' hoặc 'Ngân hàng từ chối' trong dữ liệu giao dịch, khi trạng thái đó không thay đổi về sau.

Thu thập

Suy ra từ trạng thái thất bại cuối cùng trong hồ sơ thanh toán.

Loại sự kiện inferred
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ ACI Worldwide

Bắt đầu ngay?

Dùng mẫu này làm hướng dẫn để bắt đầu trích xuất dữ liệu xử lý thanh toán. Khám phá thông tin hữu ích và cải thiện hiệu quả quy trình làm việc tài chính ngay hôm nay.

Tinh gọn quy trình xử lý thanh toán: bắt đầu dùng thử miễn phí ngay

Loại bỏ các trường hợp ngoại lệ trong thanh toán và đạt tỷ lệ xử lý tự động xuyên suốt 98%.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng, thiết lập chỉ trong vài phút