Mẫu dữ liệu quản lý tín dụng và thu hồi công nợ
Mẫu dữ liệu quản lý tín dụng và thu hồi công nợ
- Các thuộc tính nên có để phân tích đầy đủ
- Hoạt động chính cần theo dõi để khám phá quy trình
- Hướng dẫn trích xuất dữ liệu từng bước
Thuộc tính quản lý tín dụng và thu hồi công nợ
| Tên | Mô tả | ||
|---|---|---|---|
| Số hóa đơn InvoiceNumber | Mã định danh duy nhất của từng hóa đơn khách hàng, được dùng làm mã hồ sơ chính cho quy trình quản lý tín dụng. | ||
| Mô tả Số hóa đơn là khóa trung tâm liên kết mọi sự kiện và hoạt động liên quan đến một khoản phải thu, từ lúc tạo hóa đơn đến khi tất toán hoặc xóa sổ. Nhờ đó, bạn có thể xem toàn bộ vòng đời hóa đơn từ đầu đến cuối. Trong phân tích process mining, thuộc tính này được dùng để tái dựng hành trình của từng hóa đơn. Khi nhóm mọi hoạt động liên quan theo một số hóa đơn, chuyên viên phân tích có thể trực quan hóa luồng quy trình, tìm các lộ trình phổ biến và khác biệt, đồng thời đo thời gian chu kỳ của toàn bộ quy trình hoặc từng giai đoạn, chẳng hạn như giải quyết tranh chấp hay ghi nhận thanh toán. Vì sao điều này quan trọng Đây là mã hồ sơ thiết yếu, liên kết mọi bước quy trình liên quan để tái dựng và phân tích hành trình của từng hóa đơn từ lúc phát hành đến khi đóng. Lấy dữ liệu ở đâu Trong Oracle Fusion Financials, mã này thường nằm trong bảng RA_CUSTOMER_TRX_ALL dưới tên TRX_NUMBER. Ví dụ INV-1005679884321AR-2023-04-112 | |||
| Tên hoạt động ActivityName | Tên của sự kiện kinh doanh hoặc tác vụ cụ thể diễn ra tại một thời điểm trong quy trình quản lý tín dụng. | ||
| Mô tả Thuộc tính này mô tả một bước trong vòng đời hóa đơn, chẳng hạn như “Tạo hóa đơn”, “Bắt đầu quy trình nhắc nợ” hoặc “Nhận thanh toán”. Mỗi hoạt động là một sự kiện riêng giúp hồ sơ tiến triển. Phân tích trình tự và tần suất hoạt động là trọng tâm của process mining. Việc này giúp phát hiện luồng quy trình thực tế, tìm điểm nghẽn khiến hồ sơ bị mắc lại, phát hiện vòng lặp làm lại khi hoạt động bị lặp lại, và so sánh quy trình thực tế với quy trình được thiết kế hoặc lý tưởng. Tên hoạt động là yếu tố thiết yếu để xây dựng sơ đồ quy trình và tính thời gian chuyển tiếp giữa các bước. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong sơ đồ quy trình, giúp trực quan hóa và phân tích vòng đời hóa đơn từ đầu đến cuối. Lấy dữ liệu ở đâu Đây là trường khái niệm được tạo từ nhiều sự kiện kinh doanh trong Oracle Fusion Financials, thường bằng cách ánh xạ trạng thái giao dịch, ngày sự kiện hoặc hành động cụ thể từ các phân hệ như Receivables (AR) và Advanced Collections. Ví dụ Tạo hóa đơnBắt đầu quy trình nhắc nợNhận thanh toánGhi nhận tranh chấp | |||
| Thời điểm sự kiện EventTime | Ngày và giờ chính xác khi hoạt động diễn ra, được dùng làm dấu thời gian của sự kiện. | ||
| Mô tả Thời điểm sự kiện, hay dấu thời gian, ghi lại chính xác lúc một hoạt động diễn ra. Đây là thông tin thiết yếu để sắp xếp sự kiện theo trình tự thời gian và dựng luồng quy trình chính xác. Nếu dấu thời gian không chính xác, bạn không thể xác định đúng thứ tự sự kiện. Trong phân tích, thuộc tính này được dùng để tính thời lượng và thời gian chu kỳ giữa các hoạt động, yếu tố quan trọng để đo hiệu suất. Ví dụ, thuộc tính này giúp tính các KPI như Thời gian chu kỳ giải quyết tranh chấp hoặc Thời gian chu kỳ thanh toán hóa đơn. Nó cũng cho phép phân tích xu hướng hiệu suất quy trình qua các giai đoạn khác nhau. Vì sao điều này quan trọng Dấu thời gian này rất cần thiết để sắp xếp sự kiện, tính thời gian chu kỳ và thời lượng, cũng như phân tích hiệu suất quy trình theo thời gian. Lấy dữ liệu ở đâu Được lấy từ nhiều trường ngày trong các bảng Oracle Fusion Financials, chẳng hạn như TRX_DATE trong RA_CUSTOMER_TRX_ALL khi tạo hóa đơn hoặc ngày tạo một hoạt động thu hồi nợ. Ví dụ 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Hệ thống nguồn SourceSystem | Hệ thống cung cấp dữ liệu. | ||
| Mô tả Thuộc tính này xác định ứng dụng nguồn nơi dữ liệu sự kiện được ghi lại. Trong môi trường CNTT phức tạp, một quy trình từ đầu đến cuối có thể liên quan đến nhiều hệ thống. Việc chỉ rõ hệ thống nguồn rất quan trọng đối với quản trị dữ liệu, xử lý sự cố và hiểu bối cảnh dữ liệu. Nếu kết hợp sự kiện từ nhiều hệ thống vào cùng một chế độ xem quy trình, thuộc tính này giúp phân biệt nguồn của từng sự kiện và bảo đảm có thể truy xuất nguồn gốc dữ liệu. Vì sao điều này quan trọng Làm rõ nguồn gốc dữ liệu, yếu tố quan trọng để xác thực và quản trị dữ liệu cũng như hiểu bối cảnh công nghệ của quy trình. Lấy dữ liệu ở đâu Đây thường là giá trị tĩnh được thêm vào khi trích xuất dữ liệu để xác định nguồn gốc của các bản ghi. Ví dụ Oracle Fusion FinancialsOracle AROracle Collections | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian cho biết lần gần nhất dữ liệu của sự kiện được làm mới hoặc trích xuất từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này ghi lại ngày và giờ của lần trích xuất dữ liệu gần nhất. Đây là trường siêu dữ liệu, không thuộc quy trình kinh doanh, nhưng rất cần thiết để biết dữ liệu đang phân tích có mới hay không. Chuyên viên phân tích dùng dấu thời gian này để xác nhận dữ liệu đang làm việc là dữ liệu cập nhật và biết dữ liệu được lấy đến thời điểm nào. Đây là thông tin thiết yếu cho quản trị dữ liệu và giúp người dùng hiểu dữ liệu trong dashboard và báo cáo được cập nhật đến đâu. Vì sao điều này quan trọng Cho biết dữ liệu mới đến mức nào, giúp chuyên viên phân tích và các bên liên quan nắm được tính cập nhật và mức độ phù hợp của dữ liệu. Lấy dữ liệu ở đâu Giá trị này được tạo và đóng dấu thời gian trên từng bản ghi trong quá trình trích xuất và nạp dữ liệu (ETL). Ví dụ 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Cấp độ nhắc nợ DunningLevel | Giai đoạn hoặc cấp độ của quy trình nhắc nợ đã áp dụng cho hóa đơn. | ||
| Mô tả Cấp độ nhắc nợ cho biết mức độ nhắc khách hàng thanh toán, thường tăng dần theo thời gian. Ví dụ, cấp độ 1 có thể là email nhắc nhẹ nhàng, còn cấp độ 3 có thể là thư thông báo chính thức hoặc cuộc gọi. Phân tích quy trình theo cấp độ nhắc nợ giúp đánh giá hiệu quả của chiến lược nhắc nợ. Bảng điều khiển hiệu quả nhắc nợ dùng thuộc tính này để thể hiện tỷ lệ chuyển đổi từ mỗi bước nhắc nợ sang thanh toán. Nhờ đó, doanh nghiệp có thể xác định biện pháp nhắc nợ nào hiệu quả nhất, đồng thời điều chỉnh thời điểm và nội dung nhắc để tăng số tiền thu hồi. Vì sao điều này quan trọng Theo dõi giai đoạn tăng cường thu hồi công nợ, yếu tố quan trọng để đánh giá hiệu quả của chiến lược nhắc nợ. Lấy dữ liệu ở đâu Dữ liệu này được quản lý trong Oracle Advanced Collections. Bạn có thể tìm thấy dữ liệu trong các bảng lưu lịch sử nhắc nợ, chẳng hạn như IEX_DUNNINGS. Ví dụ Cấp độ 1: Nhắc nhởCấp độ 2: Cảnh báoCấp độ 3: Thông báo cuối cùng | |||
| Giá trị hóa đơn InvoiceAmount | Tổng giá trị tiền tệ của hóa đơn. | ||
| Mô tả Giá trị hóa đơn là tổng giá trị hàng hóa hoặc dịch vụ tính cho khách hàng. Đây là thuộc tính tài chính quan trọng để hiểu tác động tiền tệ của quy trình. Trong phân tích, giá trị hóa đơn giúp ưu tiên hoạt động thu hồi nợ, tập trung vào các hóa đơn quá hạn có giá trị cao. Thuộc tính này cũng được dùng để phân tích hành vi thanh toán theo giá trị giao dịch và tính tác động tài chính của các khoản xóa sổ. Các dashboard như Phân tích tỷ lệ xóa sổ hóa đơn dựa vào giá trị này để đánh giá mức độ tổn thất tài chính. Vì sao điều này quan trọng Bổ sung bối cảnh tài chính cho quy trình, giúp ưu tiên hóa đơn giá trị cao và phân tích tác động tiền tệ của những điểm kém hiệu quả. Lấy dữ liệu ở đâu Có thể lấy thông tin này từ bảng AR_PAYMENT_SCHEDULES_ALL, nơi lưu số tiền đến hạn của hóa đơn. Ví dụ 5000.001250.75250000.00 | |||
| Mã khách hàng CustomerNumber | Mã định danh duy nhất của khách hàng gắn với hóa đơn. | ||
| Mô tả Mã khách hàng liên kết hóa đơn với một tài khoản khách hàng cụ thể. Nhờ đó, bạn có thể phân nhóm và phân tích quy trình tín dụng, thu hồi nợ dựa trên đặc điểm khách hàng. Khi có mã khách hàng, chuyên viên phân tích có thể tìm hiểu liệu một số khách hàng có thường xuyên thanh toán trễ, tranh chấp nhiều hơn hoặc cần nhiều nỗ lực thu hồi nợ hơn hay không. Thông tin này rất quan trọng để xây dựng chiến lược thu hồi nợ riêng cho từng khách hàng, điều chỉnh điều khoản tín dụng và xác định nhóm khách hàng có rủi ro cao. Thuộc tính này hỗ trợ trực tiếp các phân tích như Phân tích tỷ lệ xóa sổ hóa đơn theo nhóm khách hàng. Vì sao điều này quan trọng Cho phép phân nhóm quy trình theo khách hàng để tìm ra xu hướng, rủi ro và cơ hội xây dựng chiến lược thu hồi nợ phù hợp. Lấy dữ liệu ở đâu Thường nằm trong bảng RA_CUSTOMER_TRX_ALL dưới tên BILL_TO_CUSTOMER_ID, liên kết với HZ_CUST_ACCOUNTS. Ví dụ CUST-0012389455ACME-CORP-US | |||
| Ngày đến hạn DueDate | Ngày khách hàng phải thanh toán hóa đơn. | ||
| Mô tả Ngày đến hạn là mốc thời gian quan trọng đã được thỏa thuận trong hợp đồng để thanh toán. Đây là căn cứ để đánh giá khoản thanh toán có đúng hạn hay không. Thuộc tính này giúp xác định hóa đơn quá hạn và tính số ngày quá hạn. Đây cũng là dữ liệu đầu vào chính để xác định thời điểm bắt đầu quy trình nhắc nợ và tính các KPI như số ngày phải thu bình quân (DSO). Ngoài ra, thuộc tính này cần thiết để lập báo cáo tuổi nợ, phân loại các khoản chưa thanh toán. Vì sao điều này quan trọng Là căn cứ xác định hóa đơn quá hạn, bắt đầu hoạt động thu hồi công nợ và phân tích tuổi nợ. Lấy dữ liệu ở đâu Có trong bảng AR_PAYMENT_SCHEDULES_ALL với tên trường DUE_DATE. Ví dụ 2023-05-302023-06-152023-07-01 | |||
| Người dùng User | Người dùng hoặc mã hệ thống đã thực hiện hoạt động. | ||
| Mô tả Thuộc tính này xác định nhân viên hoặc tài khoản hệ thống cụ thể chịu trách nhiệm thực hiện một hoạt động, chẳng hạn phê duyệt hạn mức tín dụng, ghi nhận khoản thanh toán hoặc giải quyết tranh chấp. Phân tích hoạt động theo người dùng giúp hiểu cách phân bổ khối lượng công việc, hiệu suất cá nhân và mức độ tuân thủ. Với các hoạt động tự động, thuộc tính này giúp theo dõi vai trò của các quy trình hệ thống. Bạn cũng có thể dùng dữ liệu để xác định nhu cầu đào tạo hoặc phát hiện dấu hiệu gian lận tiềm ẩn qua hành vi người dùng. Vì sao điều này quan trọng Gắn hoạt động trong quy trình với từng cá nhân hoặc hệ thống tự động, giúp theo dõi hiệu suất, phân tích khối lượng công việc và kiểm tra. Lấy dữ liệu ở đâu Lấy từ các cột 'CREATED_BY' hoặc 'LAST_UPDATED_BY' trong nhiều bảng giao dịch và lịch sử của Oracle Fusion Financials. Ví dụ jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Nhân viên thu hồi nợ Collector | Tên hoặc mã của nhân viên thu hồi nợ được phân công xử lý hóa đơn. | ||
| Mô tả Nhân viên thu hồi nợ là cá nhân hoặc đội ngũ chịu trách nhiệm quản lý hoạt động thu hồi đối với hóa đơn quá hạn. Việc phân công này là một bước quan trọng trong quy trình thu hồi nợ. Thuộc tính này rất quan trọng để quản lý hiệu suất và phân bổ tài nguyên trong bộ phận thu hồi nợ. Bằng cách phân tích kết quả của từng nhân viên, quản lý có thể đánh giá hiệu quả công việc, xác định nhu cầu đào tạo và cân bằng khối lượng công việc. Dashboard Hiệu quả phân công nhân viên thu hồi nợ dựa trực tiếp vào thuộc tính này để so sánh tỷ lệ thành công và thời gian chu kỳ giữa các nhân viên. Vì sao điều này quan trọng Cho phép phân tích hiệu suất của từng nhân viên hoặc đội ngũ, giúp phân bổ tài nguyên hợp lý và nâng cao hiệu quả thu hồi nợ. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong phân hệ Oracle Advanced Collections, có thể nằm trong các bảng như IEX_CASES_ALL_B hoặc bảng phân công liên quan. Ví dụ John SmithJane DoeNhóm thu hồi công nợ A | |||
| Nhóm khách hàng CustomerSegment | Phân loại khách hàng vào một nhóm xác định, chẳng hạn theo quy mô, ngành nghề hoặc tầm quan trọng chiến lược. | ||
| Mô tả Nhóm khách hàng là thuộc tính phân loại khách hàng dựa trên những đặc điểm chung. Có thể xác định nhóm theo các yếu tố như “Chiến lược”, “Doanh nghiệp nhỏ và vừa”, “Doanh nghiệp lớn” hoặc theo ngành như “Sản xuất” hay “Bán lẻ”. Thuộc tính này hữu ích cho phân tích so sánh. Chuyên viên phân tích có thể so sánh hiệu suất quy trình giữa các nhóm để xem, chẳng hạn, nhóm nào có tỷ lệ tranh chấp cao hơn hoặc chu kỳ thanh toán dài hơn. Thông tin này giúp điều chỉnh chính sách tín dụng và chiến lược thu hồi nợ theo nhu cầu và rủi ro của từng nhóm, đồng thời hỗ trợ các dashboard như Phân tích tỷ lệ xóa sổ hóa đơn. Vì sao điều này quan trọng Hỗ trợ phân tích so sánh, cho thấy hiệu suất quy trình và rủi ro khác nhau như thế nào giữa các nhóm khách hàng. Lấy dữ liệu ở đâu Thường được quản lý trong dữ liệu chính khách hàng (HZ_CUST_ACCOUNTS hoặc các bảng liên quan), hoặc suy ra từ thuộc tính khách hàng như doanh thu hay ngành nghề. Ví dụ Doanh nghiệp lớnDoanh nghiệp nhỏ và vừaChính phủĐối tác chiến lược | |||
| Đã quá hạn IsOverdue | Cờ đúng/sai cho biết hóa đơn đã quá ngày đến hạn thanh toán hay chưa. | ||
| Mô tả Đây là thuộc tính được tính toán, cho biết hóa đơn đã quá hạn hay chưa bằng giá trị đúng hoặc sai. Thông thường, thuộc tính này được tính bằng cách so sánh ngày hiện tại (hoặc ngày thanh toán) với ngày đến hạn của hóa đơn. Cờ này rất hữu ích khi lọc và phân nhóm dữ liệu phân tích. Chuyên viên phân tích có thể nhanh chóng xác định các hóa đơn quá hạn để xem xét đường đi của quy trình, hiệu quả hoạt động thu hồi công nợ và các đặc điểm liên quan. Thuộc tính này cũng giúp tạo bảng điều khiển và KPI về quản lý nợ quá hạn, chẳng hạn bảng điều khiển Tuổi nợ và trạng thái hóa đơn quá hạn. Vì sao điều này quan trọng Cung cấp cờ rõ ràng, đơn giản để xác định và phân tích tất cả hóa đơn quá hạn, nhóm trọng tâm của quy trình thu hồi công nợ. Lấy dữ liệu ở đâu Đây là trường được tính toán theo logic: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Ví dụ truefalse | |||
| Đã xóa sổ IsWrittenOff | Cờ đúng/sai cho biết hóa đơn đã được xóa sổ thành nợ xấu hay chưa. | ||
| Mô tả Cờ được tính toán này xác định các hóa đơn mà doanh nghiệp cho là không thể thu hồi và đã loại khỏi các khoản phải thu đang theo dõi. Đây thường là kết quả cuối cùng và không mong muốn của một hóa đơn. Thuộc tính này cần thiết để tính KPI tỷ lệ hóa đơn bị xóa sổ và phân tích trên bảng điều khiển liên quan. Chuyên viên phân tích có thể lọc riêng các trường hợp thu hồi thất bại để tìm đặc điểm chung, chẳng hạn phân khúc khách hàng hoặc giá trị hóa đơn, có thể liên quan đến rủi ro xóa sổ cao hơn. Doanh nghiệp có thể dùng thông tin này để cải thiện chính sách tín dụng và chiến lược thu hồi công nợ. Vì sao điều này quan trọng Xác định rõ các trường hợp thu hồi công nợ thất bại, giúp phân tích nguyên nhân gốc rễ của nợ xấu và tính tỷ lệ xóa sổ. Lấy dữ liệu ở đâu Đây là trường được tính toán, xác định bằng cách kiểm tra xem trường hợp có hoạt động 'Invoice Written Off' hay trạng thái hóa đơn là 'Written Off' hay không. Ví dụ truefalse | |||
| Điều khoản thanh toán PaymentTerms | Các điều khoản đã thỏa thuận, quy định thời hạn thanh toán. | ||
| Mô tả Điều khoản thanh toán quy định thời hạn khách hàng cần thanh toán, chẳng hạn 'Net 30' hoặc 'Net 60'. Các điều khoản này được dùng để tính ngày đến hạn của hóa đơn. Phân tích tình hình thanh toán theo điều khoản có thể cho thấy những xu hướng đáng chú ý. Chẳng hạn, khách hàng có thời hạn thanh toán ngắn hơn có thể thường trả trễ hơn. Doanh nghiệp có thể dùng thông tin này để xem xét, điều chỉnh chính sách tín dụng và chia nhóm khách hàng theo chiến lược thu hồi công nợ phù hợp. Đây cũng là cơ sở giúp lý giải vì sao một số hóa đơn bị quá hạn. Vì sao điều này quan trọng Cho biết lịch thanh toán đã thỏa thuận, giúp phân tích hành vi thanh toán theo từng điều khoản tín dụng. Lấy dữ liệu ở đâu Dữ liệu được lưu trong bảng RA_TERMS và liên kết với giao dịch hóa đơn. Ví dụ Net 30Net 60Thanh toán khi nhận hóa đơn | |||
| Đơn vị kinh doanh BusinessUnit | Đơn vị kinh doanh hoặc tổ chức cụ thể đã phát hành hóa đơn. | ||
| Mô tả Ở các tổ chức lớn, hoạt động thường được chia thành nhiều đơn vị kinh doanh. Thuộc tính này cho biết hóa đơn thuộc đơn vị nào. Phân tích quy trình theo đơn vị kinh doanh giúp so sánh hiệu quả giữa các bộ phận trong tổ chức. Qua đó, bạn có thể phát hiện sự khác biệt trong cách áp dụng chính sách tín dụng và thu hồi công nợ, đồng thời xác định đơn vị nào quản lý khoản phải thu hiệu quả hơn. Từ đó, doanh nghiệp có thể chia sẻ cách làm tốt và chuẩn hóa quy trình khi cần. Vì sao điều này quan trọng Giúp so sánh hiệu quả giữa các đơn vị trong tổ chức, từ đó 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 Có trong bảng RA_CUSTOMER_TRX_ALL qua trường ORG_ID, trường này liên kết với cơ cấu tổ chức. Ví dụ Đơn vị kinh doanh Bắc MỹĐơn vị kinh doanh EMEAKhối dịch vụ toàn cầu | |||
| Lý do tranh chấp DisputeReason | Lý do khách hàng đưa ra khi tranh chấp hóa đơn. | ||
| Mô tả Khi tranh chấp hóa đơn, khách hàng thường nêu lý do như 'Đơn giá không chính xác', 'Hàng hóa bị hư hỏng' hoặc 'Hóa đơn bị trùng'. Thuộc tính này ghi lại lý do đó. Phân tích lý do tranh chấp giúp tìm nguyên nhân gốc rễ. Qua đó, bạn có thể phát hiện các vấn đề lặp lại ở những quy trình trước đó, như quản lý đơn hàng hoặc lập hóa đơn, khiến việc thanh toán bị chậm trễ. Khi phân loại và theo dõi tần suất từng lý do, doanh nghiệp có thể xử lý đúng nguyên nhân, góp phần rút ngắn thời gian giải quyết tranh chấp. Vì sao điều này quan trọng Giúp tìm nguyên nhân gốc rễ của tranh chấp hóa đơn để cải tiến các quy trình liên quan và ngăn tranh chấp tái diễn. Lấy dữ liệu ở đâu Thông tin này thường được ghi nhận trong Oracle Advanced Collections hoặc Oracle Channel Revenue Management nếu doanh nghiệp có quy trình quản lý tranh chấp chính thức. Dữ liệu có thể nằm trong các bảng như AR_DISPUTE_HISTORY. Ví dụ Số lượng không chính xácChênh lệch giáHàng hóa bị hư hỏngChưa cung cấp dịch vụ | |||
| Ngày hứa thanh toán PromiseToPayDate | Ngày khách hàng cam kết sẽ thanh toán. | ||
| Mô tả Trong quá trình thu hồi công nợ, khách hàng có thể cam kết thanh toán vào một ngày trong tương lai. Ngày hứa thanh toán được ghi nhận để theo dõi cam kết này. Thuộc tính này giúp quản lý quy trình làm việc thu hồi công nợ và đánh giá mức độ đáng tin cậy của cam kết từ khách hàng. Bằng cách so sánh ngày hứa thanh toán với ngày thực nhận tiền, nhân viên thu hồi công nợ có thể đánh giá tỷ lệ thực hiện cam kết. Thông tin này giúp dự báo dòng tiền chính xác hơn và quyết định thời điểm tăng cường thu hồi nếu khách hàng không giữ lời hứa. Vì sao điều này quan trọng Theo dõi cam kết thanh toán của khách hàng, giúp dự báo dòng tiền vào và đánh giá hiệu quả đàm phán thu hồi công nợ. Lấy dữ liệu ở đâu Được lưu trong Oracle Advanced Collections, có thể trong các bảng như IEX_PROMISES_T. Ví dụ 2023-06-102023-06-252023-07-05 | |||
| Số ngày quá hạn DaysOverdue | Số ngày hóa đơn đã quá ngày đến hạn. | ||
| Mô tả Chỉ số được tính toán này cho biết hóa đơn chưa thanh toán bị trễ bao lâu. Chỉ số được tính bằng chênh lệch giữa ngày hiện tại (với hóa đơn đang mở) hoặc ngày thanh toán (với hóa đơn đã đóng) và ngày đến hạn. Số ngày quá hạn là thước đo quan trọng để phân tích tuổi nợ và ưu tiên hoạt động thu hồi công nợ. Đây là chỉ số chính trong bảng điều khiển Tuổi nợ và trạng thái hóa đơn quá hạn, nơi hóa đơn được chia theo nhóm tuổi nợ, chẳng hạn 1-30 ngày, 31-60 ngày. Nhờ đó, nhóm thu hồi công nợ có thể tập trung vào các khoản nợ lâu nhất và có rủi ro cao nhất. Vì sao điều này quan trọng Cho biết mức độ chậm thanh toán, là chỉ số cốt lõi để ưu tiên thu hồi công nợ và phân tích tuổi nợ. Lấy dữ liệu ở đâu Đây là trường được tính toán theo logic: CurrentDate - DueDate với hóa đơn đang mở, hoặc PaymentDate - DueDate với hóa đơn đã đóng. Ví dụ 1545920 | |||
| Số tiền hạn mức tín dụng CreditLimitAmount | Mức tín dụng tối đa được phê duyệt cho khách hàng. | ||
| Mô tả Số tiền hạn mức tín dụng là tổng mức rủi ro tín dụng mà doanh nghiệp chấp nhận đối với một khách hàng. Hạn mức này được xác định trong quá trình đánh giá tín dụng. Thuộc tính này rất cần thiết cho bảng điều khiển Tác động của quyết định hạn mức tín dụng. Bằng cách đối chiếu hạn mức được phê duyệt với tình hình thanh toán và các khoản xóa sổ sau đó, doanh nghiệp có thể đánh giá hiệu quả của chính sách quản lý rủi ro tín dụng. Phân tích cũng có thể cho thấy hạn mức quá cao có làm tăng nợ xấu hay không, từ đó giúp điều chỉnh quy trình phê duyệt tín dụng. Vì sao điều này quan trọng Giúp đánh giá hiệu quả của chính sách quản lý rủi ro tín dụng bằng cách đối chiếu hạn mức được phê duyệt với kết quả thanh toán và các khoản xóa sổ. Lấy dữ liệu ở đâu Được quản lý trong Oracle Credit Management và thường lưu trong các bảng về hồ sơ tín dụng khách hàng, chẳng hạn HZ_CUST_PROFILE_AMTS. Ví dụ 10000.0050000.00250000.00 | |||
| Thời điểm kết thúc EndTime | Dấu thời gian cho biết khi nào một hoạt động có thời lượng hoàn tất. | ||
| Mô tả Với các hoạt động có thời điểm bắt đầu và kết thúc riêng, thuộc tính này ghi lại thời điểm hoàn tất. Trong process mining, nhiều sự kiện diễn ra tức thời, nhưng một số hoạt động như 'Điều tra tranh chấp' có thể kéo dài trong một khoảng thời gian. Có thời điểm kết thúc riêng giúp tính chính xác thời gian xử lý hoạt động. Cách này chính xác hơn việc ước tính thời lượng dựa trên thời điểm bắt đầu của hoạt động kế tiếp, nhất là khi có khoảng thời gian chờ. Đây là dữ liệu quan trọng để phân tích mức độ sử dụng tài nguyên và xác định bước cụ thể nào trong quy trình mất nhiều thời gian nhất. Vì sao điều này quan trọng Giúp tính chính xác thời lượng của từng hoạt động, qua đó hiểu rõ hơn về điểm nghẽn và mức độ sử dụng tài nguyên. Lấy dữ liệu ở đâu Đây thường là thuộc tính khái niệm. Dữ liệu có thể lấy từ dấu thời gian 'cập nhật lần cuối' hoặc trường 'ngày đóng' cụ thể trong các bảng nguồn tương ứng với hoạt động. Ví dụ 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Tiền tệ của hóa đơn InvoiceCurrency | Loại tiền tệ dùng để thể hiện giá trị hóa đơn. | ||
| Mô tả Thuộc tính này cho biết loại tiền tệ của hóa đơn, chẳng hạn như USD, EUR hoặc GBP. Các tổ chức đa quốc gia thường phát hành hóa đơn bằng nhiều loại tiền tệ. Phân tích dữ liệu có nhiều loại tiền tệ cần được xử lý cẩn thận. Thuộc tính này cho phép lọc chế độ xem quy trình theo tiền tệ hoặc áp dụng tỷ giá phù hợp khi lập báo cáo tài chính hợp nhất. Nhờ đó, giá trị tiền tệ được diễn giải chính xác và các khoản tiền được so sánh trên cùng cơ sở. Vì sao điều này quan trọng Cần thiết để diễn giải chính xác dữ liệu tài chính trong môi trường đa tiền tệ và bảo đảm phân tích tài chính đáng tin cậy. Lấy dữ liệu ở đâu Thường nằm trong bảng RA_CUSTOMER_TRX_ALL dưới tên INVOICE_CURRENCY_CODE. Ví dụ USDEURGBPJPY | |||
| Trạng thái hóa đơn InvoiceStatus | Trạng thái hiện tại của hóa đơn trong vòng đời xử lý. | ||
| Mô tả Trạng thái hóa đơn cho biết hóa đơn đang ở bước nào trong quy trình. Các trạng thái thường gặp gồm 'Đang mở', 'Đã thanh toán', 'Đang tranh chấp', 'Quá hạn' hoặc 'Đã xóa sổ'. Thuộc tính này giúp bạn nắm khái quát tình hình các khoản phải thu. Trong process mining, thuộc tính này giúp lọc các trường hợp để tập trung vào nhóm cụ thể, chẳng hạn tất cả hóa đơn quá hạn chưa thanh toán. Đây là chiều phân tích quan trọng trong bảng điều khiển Tuổi nợ và trạng thái hóa đơn quá hạn. Bảng điều khiển cho bạn thấy ngay tình trạng danh mục hóa đơn và giúp ưu tiên hoạt động thu hồi công nợ. Vì sao điều này quan trọng Giúp bạn nhanh chóng nắm tình trạng hiện tại của hóa đơn, dễ lọc dữ liệu và ưu tiên hoạt động thu hồi công nợ. Lấy dữ liệu ở đâu Thường có trong bảng AR_PAYMENT_SCHEDULES_ALL, tại trường STATUS. Ví dụ Đang mởĐã đóngĐang tranh chấpĐang thu hồi công nợ | |||
Hoạt động quản lý tín dụng và thu hồi công nợ
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Bắt đầu quy trình nhắc nợ | Đánh dấu thời điểm chính thức bắt đầu quy trình nhắc nợ cho hóa đơn quá hạn, thường bao gồm việc gửi thư nhắc nợ chính thức đầu tiên. Sự kiện này thường được ghi nhận khi quy trình xử lý lô nhắc nợ chạy và đưa hóa đơn vào lô. | ||
| Vì sao điều này quan trọng Theo dõi hoạt động này rất quan trọng để đo hiệu quả nhắc nợ và mức độ tuân thủ chính sách nhắc nợ. Đây là mốc cơ sở để đo thời gian từ lúc bắt đầu nhắc nợ đến khi nhận được thanh toán. Lấy dữ liệu ở đâu Được ghi nhận trong phân hệ Oracle Advanced Collections. Ngày tạo bản ghi nhắc nợ trong các bảng như IEX_DUNNINGS, liên kết với mã giao dịch, đánh dấu sự kiện này. Thu thập Ngày tạo bản ghi trong bảng IEX_DUNNINGS gắn với hóa đơn. Loại sự kiện explicit | |||
| Đã qua hạn thanh toán | Sự kiện được tính toán khi ngày hiện tại đã qua ngày đến hạn của hóa đơn nhưng hóa đơn vẫn chưa được thanh toán đầy đủ. Sự kiện này đánh dấu thời điểm hóa đơn chuyển từ trạng thái “chưa quá hạn” sang “quá hạn”. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng, kích hoạt quy trình thu hồi nợ và nhắc nợ. Phân tích số lượng và giá trị hóa đơn đã quá hạn là việc cần thiết để quản lý vốn lưu động và đánh giá rủi ro tín dụng. Lấy dữ liệu ở đâu Sự kiện này được tính bằng cách so sánh ngày hiện tại của hệ thống với DUE_DATE trong bảng AR_PAYMENT_SCHEDULES_ALL đối với hóa đơn có STATUS là 'OP' (Open). Thu thập Sự kiện được tính toán: xảy ra khi SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Loại sự kiện calculated | |||
| Ghi nhận thanh toán cho hóa đơn | Đại diện cho việc ghi nhận khoản thanh toán đã nhận vào một hóa đơn cụ thể, làm giảm số dư còn phải trả. Đây là bước chính thức liên kết khoản thanh toán với hóa đơn. | ||
| Vì sao điều này quan trọng Hoạt động này rất quan trọng để xác nhận hóa đơn đã được thanh toán. Đây là điểm kết thúc thực sự để tính số ngày thu tiền bình quân (DSO) và chu kỳ ghi nhận thanh toán. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp từ APPLY_DATE trong bảng AR_RECEIVABLE_APPLICATIONS_ALL, liên kết khoản thu tiền mặt với giao dịch của khách hàng (hóa đơn). Thu thập APPLY_DATE trong AR_RECEIVABLE_APPLICATIONS_ALL cho hóa đơn tương ứng. Loại sự kiện explicit | |||
| Nhận thanh toán | Đánh dấu thời điểm nhận tiền từ khách hàng, dù khoản tiền có thể chưa được ghi nhận cho một hóa đơn cụ thể. Sự kiện này được ghi lại khi giao dịch nhận tiền được tạo trong hệ thống. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng trong quy trình thu hồi nợ, cho biết tiền đã được nhận. Khoảng thời gian từ mốc này đến lúc ghi nhận thanh toán cho hóa đơn cho thấy hiệu quả xử lý nội bộ. Lấy dữ liệu ở đâu Được ghi nhận trực tiếp từ RECEIPT_DATE trong bảng AR_CASH_RECEIPTS_ALL. Sau đó, có thể liên kết khoản thu với hóa đơn được thanh toán thông qua AR_RECEIVABLE_APPLICATIONS_ALL. Thu thập RECEIPT_DATE trong AR_CASH_RECEIPTS_ALL, được liên kết thông qua các bảng ghi nhận thanh toán. Loại sự kiện explicit | |||
| Tạo hóa đơn | Đánh dấu thời điểm tạo bản ghi giao dịch hóa đơn trong Oracle Fusion Financials. Đây là điểm bắt đầu chính thức trong vòng đời hóa đơn ở phân hệ khoản phải thu và là mốc khởi đầu để phân tích. | ||
| Vì sao điều này quan trọng Đây là sự kiện bắt đầu quan trọng trong hành trình của hóa đơn. Mọi phép tính thời gian chu kỳ tiếp theo, chẳng hạn như số ngày thu tiền bình quân (DSO) và thời gian chu kỳ thanh toán hóa đơn, đều dựa trên dấu thời gian ban đầu này. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận trực tiếp từ cột CREATION_DATE hoặc TRX_DATE trong bảng RA_CUSTOMER_TRX_ALL cho một TRX_NUMBER (số hóa đơn) cụ thể. Thu thập Thời điểm sự kiện là CREATION_DATE trong bảng RA_CUSTOMER_TRX_ALL. Loại sự kiện explicit | |||
| Xóa sổ hóa đơn | Đại diện cho quyết định chính thức ngừng thu hồi và ghi nhận số tiền hóa đơn thành nợ xấu. Đây là giao dịch tài chính được ghi nhận trực tiếp, điều chỉnh số dư hóa đơn về 0. | ||
| Vì sao điều này quan trọng Đây là điểm kết thúc thất bại quan trọng của quy trình thu hồi nợ. Phân tích các khoản xóa sổ theo nhóm khách hàng, khu vực hoặc hạn mức tín dụng giúp điều chỉnh chính sách tín dụng và chiến lược thu hồi nợ để giảm tổn thất. Lấy dữ liệu ở đâu Được ghi nhận trực tiếp khi tạo khoản điều chỉnh trong bảng AR_ADJUSTMENTS_ALL với RECEIVABLES_TRX_ID trỏ đến hoạt động nợ xấu hoặc xóa sổ. Thu thập Ngày tạo bản ghi trong AR_ADJUSTMENTS_ALL có loại hoạt động xóa sổ. Loại sự kiện explicit | |||
| Đóng hóa đơn | Xảy ra khi số dư còn phải trả của hóa đơn về 0, do thanh toán, ghi nhận giấy báo có hoặc điều chỉnh. Đây là dấu mốc hoàn tất thành công vòng đời hóa đơn. | ||
| Vì sao điều này quan trọng Sự kiện này là một trong những điểm kết thúc thành công chính của quy trình. Theo dõi việc đóng hóa đơn là điều cần thiết để hiểu tình hình chung của danh mục khoản phải thu. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái trong bảng AR_PAYMENT_SCHEDULES_ALL, khi STATUS chuyển thành 'CL' (Closed). Dấu thời gian là LAST_UPDATE_DATE của lần thay đổi này. Thu thập Phát hiện khi AR_PAYMENT_SCHEDULES_ALL.STATUS chuyển thành 'CL' cho hóa đơn. Loại sự kiện inferred | |||
| Ghi nhận tranh chấp | Cho biết khách hàng đã chính thức tranh chấp một phần hoặc toàn bộ hóa đơn. Thông tin này thường được ghi nhận qua thay đổi trạng thái trong lịch thanh toán của hóa đơn. | ||
| Vì sao điều này quan trọng Hoạt động này là điểm bắt đầu của quy trình giải quyết tranh chấp. Phân tích thời gian từ lúc ghi nhận đến khi giải quyết xong là việc cần thiết để tìm ra điểm nghẽn làm chậm quá trình thu tiền. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái trong bảng AR_PAYMENT_SCHEDULES_ALL, khi trường STATUS chuyển thành 'DS' (Disputed). Có thể lấy dấu thời gian từ bảng kiểm toán hoặc ngày cập nhật gần nhất. Thu thập Phát hiện khi AR_PAYMENT_SCHEDULES_ALL.STATUS chuyển thành 'DS' cho hóa đơn. Loại sự kiện inferred | |||
| Giải quyết tranh chấp | Cho biết tranh chấp đã ghi nhận được điều tra và đã có kết quả xử lý. Sự kiện này được ghi nhận khi trạng thái tranh chấp của hóa đơn được gỡ bỏ. | ||
| Vì sao điều này quan trọng Sự kiện này đánh dấu kết thúc chu kỳ giải quyết tranh chấp. Thời gian từ “Ghi nhận tranh chấp” đến sự kiện này là KPI quan trọng để đo hiệu quả vận hành và tác động đến dòng tiền. Lấy dữ liệu ở đâu Suy ra khi STATUS trong AR_PAYMENT_SCHEDULES_ALL chuyển từ 'DS' (Disputed) về 'OP' (Open) hoặc thành 'CL' (Closed) sau khi có giấy báo có hoặc điều chỉnh. Thu thập Phát hiện khi AR_PAYMENT_SCHEDULES_ALL.STATUS chuyển từ 'DS' sang trạng thái khác. Loại sự kiện inferred | |||
| Gửi hóa đơn cho khách hàng | Cho biết hóa đơn đã được gửi chính thức cho khách hàng, qua phương thức điện tử hoặc bản in. Sự kiện này có thể được ghi trực tiếp trong phân hệ gửi hóa đơn hoặc suy ra từ ngày in hóa đơn. | ||
| Vì sao điều này quan trọng Hoạt động này đánh dấu thời điểm bắt đầu tính hạn thanh toán của khách hàng. Theo dõi mốc này giúp tính chính xác số ngày quá hạn và phân tích chậm trễ giữa lúc tạo hóa đơn và lúc thông báo cho khách hàng. Lấy dữ liệu ở đâu Có thể lấy từ LAST_PRINTED_DATE trong RA_CUSTOMER_TRX_ALL. Ngoài ra, có thể suy ra từ nhật ký tích hợp với hệ thống gửi email hoặc nền tảng liên lạc khác. Thu thập Dùng LAST_PRINTED_DATE trong RA_CUSTOMER_TRX_ALL hoặc trạng thái trong nhật ký gửi hóa đơn. Loại sự kiện inferred | |||
| Hoàn tất hoạt động thu hồi nợ | Đại diện cho một hoạt động do nhân viên thu hồi nợ thực hiện, chẳng hạn như gọi điện, gửi email hoặc ghi chú về lần trao đổi. Các hoạt động này được ghi lại dưới dạng “activities” hoặc “interactions” trong phân hệ thu hồi nợ. | ||
| Vì sao điều này quan trọng Theo dõi hoạt động của nhân viên thu hồi nợ giúp đo hiệu quả của quy trình thu hồi nợ thủ công. Qua đó, bạn có thể phân tích tần suất hoạt động và mối liên hệ giữa hoạt động với khả năng thu được thanh toán. Lấy dữ liệu ở đâu Lấy từ các bảng lịch sử tương tác hoặc hoạt động trong Oracle Advanced Collections, chẳng hạn như JTF_IH_ACTIVITIES, liên kết với khách hàng và có thể cả hóa đơn cụ thể. Thu thập Dấu thời gian tạo bản ghi trong JTF_IH_ACTIVITIES có mã kết quả hoặc lý do phù hợp. Loại sự kiện explicit | |||
| Hoàn tất rà soát tín dụng | Cho biết đã hoàn tất đánh giá tín dụng của khách hàng gắn với hóa đơn. Sự kiện này thường được suy ra bằng cách đối chiếu ngày tạo hóa đơn với ngày hoàn tất rà soát tín dụng gần nhất của tài khoản khách hàng, làm mốc cơ sở cho phân tích liên quan đến tín dụng. | ||
| Vì sao điều này quan trọng Phân tích khoảng thời gian từ lúc rà soát tín dụng đến khi đặt hàng giúp phát hiện chậm trễ ở những bước đầu của chu kỳ từ đặt hàng đến thu tiền. Đây là cơ sở để đo KPI Thời gian chu kỳ phê duyệt tín dụng và hiểu tác động của quyết định tín dụng. Lấy dữ liệu ở đâu Suy ra bằng cách truy vấn HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE của khách hàng trên hóa đơn (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Thời điểm sự kiện là LAST_CREDIT_REVIEW_DATE gần nhất trước CREATION_DATE của hóa đơn. Thu thập Liên kết hóa đơn với ngày rà soát tín dụng gần nhất của khách hàng trước khi tạo hóa đơn. Loại sự kiện inferred | |||
| Phân công chiến lược thu hồi nợ | Xảy ra khi chiến lược thu hồi nợ tự động được áp dụng cho hóa đơn hoặc khách hàng quá hạn. Chiến lược này xác định chuỗi bước và hoạt động mà hệ thống hoặc nhân viên thu hồi nợ sẽ thực hiện. | ||
| Vì sao điều này quan trọng Sự kiện này cho thấy mức độ tự động hóa trong quy trình thu hồi nợ. Phân tích các chiến lược được áp dụng và kết quả của chúng giúp tối ưu cách thu hồi nợ cho từng nhóm khách hàng. Lấy dữ liệu ở đâu Được ghi nhận trong phân hệ Oracle Advanced Collections. Thông tin thường được tìm thấy bằng cách xem ngày tạo lần phân công chiến lược trong các bảng như IEX_STRATEGIES hoặc đối tượng liên quan. Thu thập Ngày tạo mục công việc của chiến lược trong các bảng thu hồi nợ, liên kết với khách hàng hoặc giao dịch. Loại sự kiện explicit | |||
| Tạo cam kết thanh toán | Đại diện cho thỏa thuận chính thức được ghi nhận trong hệ thống, theo đó khách hàng cam kết thanh toán vào một ngày cụ thể. Đây là kết quả quan trọng của các hoạt động thu hồi nợ. | ||
| Vì sao điều này quan trọng Theo dõi cam kết thanh toán và tỷ lệ thực hiện cam kết là KPI quan trọng để đánh giá nhân viên thu hồi nợ. Thông tin này giúp dự báo dòng tiền từ các khoản phải thu quá hạn và đánh giá hiệu quả của nhân viên. Lấy dữ liệu ở đâu Được tạo trực tiếp trong Oracle Advanced Collections. Ngày tạo được lấy từ bảng IEX_PROMISE_DETAILS. Thu thập Ngày tạo trong bảng IEX_PROMISE_DETAILS tương ứng với hóa đơn. Loại sự kiện explicit | |||
Hướng dẫn trích xuất dữ liệu
Các bước
- Mở Oracle BI Publisher: Đăng nhập vào môi trường Oracle Fusion Financials. Mở khu vực Reports and Analytics bằng cách nhấp vào biểu tượng Navigator, rồi chọn Tools > Reports and Analytics.
- Tạo Data Model mới: Trong ngăn Reports and Analytics, nhấp vào nút 'Browse Catalog'. Trong danh mục, nhấp vào menu thả xuống 'New' và chọn 'Data Model'.
- Tạo tập dữ liệu SQL Query: Trong trình chỉnh sửa Data Model, nhấp vào biểu tượng '+' để thêm tập dữ liệu mới, rồi chọn 'SQL Query'.
- Cấu hình nguồn dữ liệu: Trong cửa sổ tập dữ liệu mới, đặt tên dễ hiểu, chẳng hạn 'CreditCollectionsEventLog'. Chọn 'FSCM' hoặc cơ sở dữ liệu ứng dụng Oracle Fusion phù hợp làm Data Source. Đặt Type of SQL thành 'Standard SQL'.
- Nhập SQL Query: Sao chép toàn bộ SQL query trong phần 'query' của tài liệu này và dán vào vùng văn bản SQL Query.
- Đặt tham số truy vấn: Truy vấn dùng các tham số như
:P_START_DATEvà:P_END_DATEđể lọc khoảng ngày. BI Publisher sẽ tự nhận diện các tham số này. Bạn có thể cấu hình để người dùng nhập giá trị, đồng thời đặt kiểu dữ liệu là 'Date'. - Lưu và kiểm tra Data Model: Lưu Data Model vào thư mục dùng chung hoặc thư mục riêng. Để kiểm tra truy vấn, mở thẻ 'Data', nhập giá trị tham số mẫu, chẳng hạn một khoảng ngày gần đây, rồi nhấp 'View' để xem dữ liệu đầu ra mẫu. Kiểm tra để bảo đảm các cột đều hiển thị chính xác.
- Tạo báo cáo mới: Quay lại danh mục, nhấp vào menu thả xuống 'New' và chọn 'Report'. Trong hộp thoại 'Create Report', chọn 'Use Data Model' rồi tìm Data Model bạn vừa lưu.
- Cấu hình thuộc tính báo cáo: Trong trình chỉnh sửa báo cáo, bố cục bảng đơn giản là đủ để trích xuất dữ liệu. Đặt định dạng đầu ra mặc định. Với process mining, nên dùng CSV. Để chọn định dạng này, nhấp 'View a List', tìm 'CSV' trong danh sách 'Output Formats' và đánh dấu vào ô tương ứng. Bạn có thể bỏ chọn các định dạng khác để giao diện dễ dùng hơn.
- Lưu báo cáo: Lưu báo cáo vào cùng thư mục với Data Model.
- Lên lịch trích xuất: Bạn có thể lên lịch chạy báo cáo để tự động trích xuất dữ liệu. Mở báo cáo, nhấp 'Actions' rồi chọn 'Schedule'. Đặt tần suất, chẳng hạn hằng ngày, chọn CSV làm định dạng đầu ra và chỉ định nơi nhận dữ liệu, như thư mục trên content server hoặc máy chủ bên ngoài qua FTP.
Cấu hình
- Điều kiện tiên quyết: Người tạo và chạy báo cáo cần có vai trò BI phù hợp, chẳng hạn 'BI Administrator' hoặc 'BI Author', cùng quyền bảo mật dữ liệu để truy cập các bảng Financials liên quan (AR, IEX, HZ, JTF).
- Nguồn dữ liệu: Nên chạy truy vấn trên cơ sở dữ liệu ứng dụng chính, thường có tên 'FSCM'.
- Tham số khoảng ngày: Cần dùng tham số
:P_START_DATEvà:P_END_DATEđể giới hạn lượng dữ liệu. Khi kiểm tra ban đầu, hãy chọn khoảng ngắn, chẳng hạn một tháng. Khi chạy chính thức, thường nên lấy dữ liệu cuốn chiếu trong 3 đến 6 tháng. - Lọc dữ liệu: Với tổ chức lớn, hãy cân nhắc thêm tham số
BU_NAME(Business Unit Name) vào mệnh đềWHEREtrong biểu thức bảng chunginvoices_baseđể xử lý từng đơn vị kinh doanh. - Lưu ý về hiệu suất: Truy vấn kết hợp nhiều bảng giao dịch lớn. Nếu chạy trên khoảng ngày rộng mà không lọc, thời gian thực thi trong BI Publisher có thể kéo dài hoặc hết thời gian chờ. Hãy lên lịch chạy báo cáo vào giờ thấp điểm.
- Định dạng đầu ra: Đặt CSV làm định dạng đầu ra mặc định hoặc định dạng theo lịch. CSV tạo tệp phân tách rõ ràng, dễ dùng với các công cụ process mining. Kiểm tra thuộc tính đầu ra CSV để bảo đảm dấu phân cách và mã hóa ký tự được đặt đúng.
Truy vấn mẫu sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off'Bạn đã sẵn sàng bắt đầu chưa?
Dùng mẫu này để chuẩn bị dữ liệu phân tích, từ đó hiểu rõ hơn về quy trình quản lý tín dụng và thu hồi công nợ. Bắt đầu cải tiến quy trình ngay hôm nay.
Bắt đầu tối ưu quản lý tín dụng và thu hồi công nợ ngay hôm nay
Rút ngắn 30% thời gian xử lý và cải thiện tình hình tài chính trong Oracle Fusion.
Không cần thẻ tín dụng. Bắt đầu chỉ trong vài phút.