> Cải tiến quy trình liên tục > Quy trình xử lý đơn bán hàng từ đơn hàng đến thu tiền > Oracle Fusion Financials > Mẫu dữ liệu

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Oracle Fusion Financials

← Quay lại hướng dẫn cải tiến

Các thuộc tính của quy trình xử lý đơn hàng đến thu tiền(23) Các hoạt động trong quy trình xử lý đơn hàng đến thu tiền(14) Hướng dẫn trích xuất(2)

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình xử lý đơn hàng đến thu tiền. Mẫu nêu rõ các thuộc tính cần thu thập và hoạt động cần theo dõi để bạn có cái nhìn đầy đủ về quy trình. Bạn cũng sẽ tìm thấy hướng dẫn thực tế về cách trích xuất dữ liệu từ hệ thống nguồn để bắt đầu nhanh chóng.

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 thực tế

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.

Tải mẫu xuống

Các thuộc tính của quy trình xử lý đơn hàng đến thu tiền

Đây là những trường dữ liệu nên có trong nhật ký sự kiện để phân tích và tìm hiểu sâu về quy trình xử lý đơn hàng đến thu tiền.

3 Bắt buộc 8 Nên có 12 Không bắt buộc

	Tên	Mô tả
	Đơn hàng bán SalesOrder	Mã định danh duy nhất của đơn hàng bán, được dùng làm hồ sơ chính trong quy trình từ đơn hàng đến thu tiền.
Mô tả Số đơn hàng bán xác định duy nhất từng đơn hàng của khách trong suốt vòng đời của đơn. Số này kết nối mọi hoạt động liên quan, từ lúc tạo và xác nhận đơn đến khi thực hiện, lập hóa đơn và nhận thanh toán cuối cùng. Trong process mining, thuộc tính này rất cần thiết để nhóm mọi sự kiện liên quan vào cùng một hồ sơ. Phân tích theo đơn hàng bán giúp bạn theo dõi toàn bộ quy trình từ đầu đến cuối, tính tổng thời gian chu trình, xác định các biến thể quy trình của từng đơn và theo dõi hành trình đơn hàng qua nhiều phòng ban, hệ thống. Vì sao điều này quan trọng Đây là Case ID. Mã này liên kết mọi sự kiện trong quy trình, giúp bạn theo dõi hành trình từ đầu đến cuối của một đơn hàng khách hàng. Lấy dữ liệu ở đâu Thông thường, mã này nằm trong bảng phần đầu đơn hàng bán của Oracle Fusion, chẳng hạn như DOO_HEADERS_ALL. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ SO-100567SO-100568SO-100569
	Tên hoạt động ActivityName	Tên của sự kiện nghiệp vụ hoặc tác vụ cụ thể đã diễn ra trong quy trình đơn hàng bán.
Mô tả Thuộc tính này mô tả bước được thực hiện tại một thời điểm cụ thể trong quy trình đơn hàng bán, chẳng hạn như “Đã tạo đơn hàng bán”, “Đã giao hàng” hoặc “Đã nhận thanh toán”. Chuỗi hoạt động này tạo thành luồng quy trình của từng hồ sơ. Phân tích ActivityName là nền tảng của process mining. Thuộc tính này giúp trực quan hóa sơ đồ quy trình, tìm ra các biến thể quy trình và xác định điểm nghẽn nơi các hồ sơ bị dồn lại. Đây cũng là cơ sở để tính thời gian chuyển tiếp giữa các bước và hiểu trình tự vận hành của quy trình từ đơn hàng đến thu tiền. Vì sao điều này quan trọng Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp trực quan hóa và phân tích luồng quy trình. Lấy dữ liệu ở đâu Đây là thuộc tính được tạo ra bằng cách ánh xạ trạng thái giao dịch hoặc loại sự kiện từ nhiều bảng Oracle Fusion, chẳng hạn như trạng thái đơn hàng, trạng thái giao hàng và trạng thái hóa đơn, sang danh sách tên hoạt động đã chuẩn hóa. Ví dụ Đã tạo đơn hàng bánĐã gửi hàngĐã tạo hóa đơnĐã nhận thanh toán
	Thời điểm sự kiện EventTime	Dấu thời gian cho biết một hoạt động hoặc sự kiện cụ thể của đơn hàng bán đã diễn ra khi nào.
Mô tả Thuộc tính này ghi ngày giờ của từng hoạt động trong quy trình, qua đó xác định trình tự thời gian của các sự kiện. Đây là cơ sở thời gian cho việc phân tích quy trình, ghi lại chính xác thời điểm từng bước diễn ra. Trong process mining, EventTime rất quan trọng để tính thời gian chu trình, khoảng thời gian giữa các hoạt động và tổng thời gian xử lý hồ sơ. Thuộc tính này hỗ trợ phân tích hiệu suất, phát hiện điểm nghẽn dựa trên thời gian chờ và theo dõi việc tuân thủ các thỏa thuận mức dịch vụ (SLA) về thời hạn. Mọi KPI và dashboard dựa trên thời gian đều cần thuộc tính này chính xác. 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 theo trình tự thời gian và tính mọi chỉ số dựa trên thời gian, chẳng hạn như thời gian chu trình và khoảng thời gian xử lý. Lấy dữ liệu ở đâu Đây là thuộc tính được tổng hợp từ nhiều trường dấu thời gian trong các bảng Oracle Fusion, chẳng hạn như ngày tạo đơn hàng, ngày giao hàng, ngày lập hóa đơn và ngày thanh toán. Ví dụ 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z
	Được tự động hóa IsAutomated	Cờ cho biết hoạt động do hệ thống tự động thực hiện hay do người dùng thao tác thủ công.
Mô tả Thuộc tính dạng đúng/sai này phân biệt sự kiện do hệ thống xử lý, chẳng hạn kiểm tra tín dụng tự động hoặc tạo hóa đơn tự động, với thao tác thủ công của người dùng. Thuộc tính thường được xác định dựa trên tên người dùng gắn với hoạt động, trong đó mã hệ thống chung cho biết hoạt động được tự động hóa. Phân tích thuộc tính này giúp đo mức độ tự động hóa của quy trình và là dữ liệu đầu vào trực tiếp cho KPI “Tỷ lệ đơn hàng phải làm lại thủ công”. Thuộc tính có thể cho thấy cơ hội tự động hóa thêm bằng cách xác định bước thủ công nào tốn nhiều thời gian hoặc dễ xảy ra lỗi nhất. Vì sao điều này quan trọng Giúp định lượng mức độ tự động hóa trong quy trình và xác định cơ hội giảm các thao tác thủ công tốn kém. Lấy dữ liệu ở đâu Đây là trường được tạo ra, thường dựa trên quy tắc áp dụng cho thuộc tính UserName. Ví dụ, nếu người dùng là “SYSTEM” hoặc “BATCH”, cờ này được đặt thành true. Ví dụ truefalse
	Kênh bán hàng SalesChannel	Kênh tiếp nhận đơn hàng bán.
Mô tả Thuộc tính này phân loại nguồn tiếp nhận đơn hàng bán, chẳng hạn “Web”, “Bán hàng trực tiếp”, “Đối tác” hoặc “EDI”. Thuộc tính cho biết đơn hàng đi vào tổ chức qua kênh nào. Phân nhóm quy trình theo kênh bán hàng rất quan trọng đối với dashboard “Tổng quan hiệu suất kênh bán hàng”. Dashboard giúp so sánh hiệu quả, thời gian chu trình và tỷ lệ lỗi giữa các kênh để xác định kênh nào hoạt động tốt nhất và kênh nào cần cải tiến quy trình hoặc tự động hóa thêm. Vì sao điều này quan trọng Hỗ trợ phân tích hiệu suất theo kênh, giúp xác định kênh xử lý đơn hàng hiệu quả nhất và kém hiệu quả nhất. Lấy dữ liệu ở đâu Thông tin này có thể được lưu trong một trường riêng trên phần đầu đơn hàng bán. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ Bán hàng trực tiếpCổng thông tin webEDIĐại lý bán lại
	Ngày đến hạn thanh toán PaymentDueDate	Ngày cuối cùng khách hàng phải 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 lập hóa đơn và điều khoản thanh toán đã thỏa thuận với khách hàng. Ngày này xác định hạn chót để thu tiền đúng hạn. Thuộc tính này rất quan trọng để tính KPI “Tỷ lệ thu tiền đúng hạn”. So sánh PaymentDueDate với ngày thực tế nhận thanh toán giúp hệ thống xác định khoản thanh toán đúng hạn hay trễ hạn, từ đó theo dõi hiệu suất khoản phải thu và quản lý dòng tiền. Vì sao điều này quan trọng Là hạn chót để tính tỷ lệ thanh toán đúng hạn, một chỉ số quan trọng về hiệu quả dòng tiền. Lấy dữ liệu ở đâu Có trong các bảng khoản phải thu hoặc hóa đơn của Oracle Fusion, chẳng hạn AR_PAYMENT_SCHEDULES_ALL. Ví dụ 2023-06-192023-07-012023-06-25
	Ngày giao hàng khách yêu cầu RequestedDeliveryDate	Ngày giao hàng theo yêu cầu của khách hàng.
Mô tả Thuộc tính này ghi nhận ngày khách hàng muốn nhận hàng. Đây là mục tiêu hiệu suất quan trọng của khâu thực hiện đơn hàng trong quy trình từ đơn hàng đến thu tiền. Ngày này rất cần thiết để tính KPI “Tỷ lệ giao hàng đúng hạn” và hỗ trợ dashboard “Thỏa thuận mức dịch vụ giao hàng (SLA)”. Khi so sánh ngày này với ActualDeliveryDate, tổ chức có thể đo lường khả năng đáp ứng kỳ vọng của khách hàng và xác định nguyên nhân gốc rễ gây chậm giao hàng. Vì sao điều này quan trọng Làm mốc để đo hiệu suất giao hàng đúng hạn và mức độ tuân thủ thỏa thuận mức dịch vụ (SLA) với khách hàng. Lấy dữ liệu ở đâu Thường nằm trong các bảng dòng đơn hàng bán của Oracle Fusion. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ 2023-05-202023-06-012023-05-25
	Ngày giao hàng thực tế ActualDeliveryDate	Ngày hàng hóa thực sự được giao cho khách hàng.
Mô tả Thuộc tính này ghi nhận ngày giao hàng cuối cùng, đánh dấu thời điểm hoàn tất khâu thực hiện đơn hàng. Đây là kết quả thực tế để so sánh với ngày dự kiến hoặc ngày khách yêu cầu. So sánh ngày này với RequestedDeliveryDate để tính hiệu suất giao hàng đúng hạn. Đây là dữ liệu đầu vào quan trọng cho KPI “Tỷ lệ giao hàng đúng hạn” và dashboard “SLA giao hàng”, giúp đánh giá rõ hiệu quả logistics và chuỗi cung ứng. Vì sao điều này quan trọng Đây là ngày giao hàng thực tế, dùng để tính tỷ lệ giao hàng đúng hạn và đánh giá hiệu suất thực hiện đơn hàng so với yêu cầu của khách. Lấy dữ liệu ở đâu Lấy từ các bảng giao dịch vận chuyển và giao hàng trong Oracle Fusion. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ 2023-05-202023-06-032023-05-25
	Tên khách hàng CustomerName	Tên khách hàng đã đặt đơn hàng bán.
Mô tả Thuộc tính này xác định tên pháp lý của tài khoản khách hàng gắn với đơn hàng bán. Đây là chiều phân tích quan trọng để phân nhóm và xem xét quy trình từ góc độ khách hàng. Phân tích theo khách hàng giúp xác định khách hàng nào thường có thời gian chu trình dài hơn, phải làm lại nhiều hơn hoặc gặp sai lệch quy trình cụ thể. Bạn có thể dùng thông tin này để cải thiện dịch vụ khách hàng, điều chỉnh quy trình cho khách hàng trọng điểm và tìm hiểu vấn đề ảnh hưởng đến mức độ hài lòng của khách hàng. Vì sao điều này quan trọng Hỗ trợ phân tích theo khách hàng để xác định vấn đề quy trình ảnh hưởng đến từng khách hàng và cải thiện mức độ hài lòng. Lấy dữ liệu ở đâu Lấy từ các bảng dữ liệu khách hàng chính, chẳng hạn HZ_PARTIES, rồi liên kết với đơn hàng bán qua mã khách hàng. Ví dụ Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC
	Tên người dùng UserName	Tên hoặc mã người dù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 người dùng hệ thống chịu trách nhiệm thực hiện một bước cụ thể trong quy trình. Bạn có thể dùng thuộc tính này để phân tích hiệu suất theo người dùng, phân bổ khối lượng công việc và mức độ tuân thủ quy trình chuẩn. Phân tích theo người dùng giúp xác định nhu cầu đào tạo, ghi nhận cá nhân hoặc nhóm có hiệu suất cao và tìm hiểu sai lệch do người dùng cụ thể gây ra. Thuộc tính này cũng hữu ích cho việc tuân thủ và kiểm toán, giúp theo dõi ai đã thực hiện hành động nào. Vì sao điều này quan trọng Hỗ trợ phân tích hiệu suất theo người dùng, phân bổ khối lượng công việc và xác định các trường hợp phải làm lại thủ công gắn với từng cá nhân. Lấy dữ liệu ở đâu Thường lấy từ các trường như CREATED_BY hoặc LAST_UPDATED_BY trong bảng giao dịch Oracle Fusion, thường được liên kết với bảng người dùng như FND_USER. Ví dụ john.smithjane.doesystem_batch_user
	Tổng giá trị đơn hàng bán SalesOrderTotalAmount	Tổng giá trị tiền tệ của đơn hàng bán.
Mô tả Thuộc tính này thể hiện tổng số tiền khách hàng phải trả cho toàn bộ đơn hàng bán. Giá trị này gồm tổng các mặt hàng, thuế và khoản phí khác, trước khi áp dụng chiết khấu. Trong phân tích quy trình, thuộc tính này rất cần thiết cho process mining theo giá trị. Bạn có thể phân nhóm đơn hàng theo giá trị, chẳng hạn đơn giá trị cao và thấp, để xem chúng có đi theo luồng quy trình khác nhau hoặc có thời gian chu trình khác nhau không. Thuộc tính này cũng giúp ưu tiên cải tiến quy trình ở những hồ sơ có ảnh hưởng tài chính lớn nhất. Vì sao điều này quan trọng Hỗ trợ phân tích tác động tài chính, giúp ưu tiên cải tiến quy trình cho đơn hàng giá trị cao và hiểu các yếu tố làm phát sinh chi phí. Lấy dữ liệu ở đâu Thường có trong bảng phần đầu đơn hàng bán của Oracle Fusion. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ 5250.00125000.75980.50
	Điều khoản thanh toán PaymentTerms	Điều khoản thanh toán đã thỏa thuận với khách hàng.
Mô tả Thuộc tính này nêu các điều kiện khách hàng cần tuân theo khi thanh toán hóa đơn, chẳng hạn “Net 30” hoặc “Net 60”. Đây là cơ sở để tính PaymentDueDate. Trong phân tích, phân nhóm theo điều khoản thanh toán giúp giải thích khác biệt về thời gian chu trình thanh toán. Thuộc tính này cung cấp bối cảnh cho KPI “Tỷ lệ thanh toán đúng hạn”, vì các điều khoản khác nhau thường dẫn đến hành vi thanh toán khác nhau. Thông tin này có thể hỗ trợ chính sách tín dụng và dự báo dòng tiền. Vì sao điều này quan trọng Cung cấp bối cảnh quan trọng để phân tích hành vi thanh toán và giải thích khác biệt về thời gian từ lúc lập hóa đơn đến khi nhận thanh toán. Lấy dữ liệu ở đâu Có ở cấp đơn hàng bán hoặc tài khoản khách hàng trong Oracle Fusion. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ Net 30Net 60Thanh toán khi nhận hàng
	Đơn vị kinh doanh BusinessUnitName	Tên đơn vị kinh doanh nội bộ chịu trách nhiệm về đơn hàng bán.
Mô tả Thuộc tính này cho biết bộ phận hoặc đơn vị vận hành cụ thể trong công ty sở hữu giao dịch. Thuộc tính giúp so sánh hiệu suất giữa các bộ phận khác nhau trong tổ chức. Phân nhóm quy trình theo đơn vị kinh doanh giúp xác định khác biệt về hiệu quả, chi phí và tuân thủ giữa các bộ phận. Phân tích này có thể tìm ra cách làm tốt ở các đơn vị có hiệu suất cao để chia sẻ, hoặc chỉ ra đơn vị hoạt động chưa tốt cần cải tiến quy trình có trọng tâm. Vì sao điều này quan trọng Hỗ trợ so sánh hiệu suất và phân tích tính nhất quán của quy trình giữa các đơn vị trong tổ chức. Lấy dữ liệu ở đâu Thông tin này thường có trên phần đầu đơn hàng bán và được liên kết với cơ cấu tổ chức đã thiết lập trong Oracle Fusion. Ví dụ ĐV-North AmericaĐV-EMEADịch vụ toàn cầu
	Giao hàng đúng hạn IsOnTimeDelivery	Cờ được tính là true nếu hàng được giao vào hoặc trước ngày giao hàng khách yêu cầu.
Mô tả Thuộc tính dạng đúng/sai này được xác định bằng cách so sánh ActualDeliveryDate với RequestedDeliveryDate. Thuộc tính cung cấp chỉ báo đơn giản về hiệu suất giao hàng ở cấp hồ sơ. Cờ này là cơ sở để tính KPI tổng hợp “Tỷ lệ giao hàng đúng hạn”. Cờ giúp lọc và phân tích dễ dàng, cho phép người dùng nhanh chóng tìm các đơn hàng giao trễ để phân tích nguyên nhân gốc rễ dẫn đến chậm trễ. Vì sao điều này quan trọng Đo trực tiếp hiệu suất thực hiện đơn hàng so với kỳ vọng của khách hàng và giúp phân tích các đơn hàng giao trễ dễ dàng hơn. Lấy dữ liệu ở đâu Đây là trường được tính toán theo logic: ActualDeliveryDate <= RequestedDeliveryDate. Ví dụ truefalse
	Hệ thống nguồn SourceSystemIdentifier	Xác định hệ thống nguồn nơi trích xuất dữ liệu sự kiện.
Mô tả Thuộc tính này cho biết dữ liệu đến từ đâu, đặc biệt hữu ích khi quy trình từ đơn hàng đến thu tiền liên quan đến nhiều hệ thống. Ví dụ, dữ liệu đơn hàng có thể đến từ Oracle Fusion, còn dữ liệu giao hàng có thể đến từ hệ thống logistics của bên thứ ba. Khi phân tích, thuộc tính này giúp bạn hiểu nguồn gốc dữ liệu và lọc chế độ xem quy trình để chỉ xem sự kiện từ một hệ thống cụ thể. Đây là thông tin quan trọng để xác thực dữ liệu và phát hiện quy trình bị phân mảnh giữa các hệ thống CNTT. Vì sao điều này quan trọng Cho biết nguồn gốc dữ liệu, yếu tố quan trọng để quản trị dữ liệu và xử lý sự cố trong môi trường có nhiều hệ thống. Lấy dữ liệu ở đâu Thông thường, đây là giá trị tĩnh được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu. Ví dụ Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP
	Hóa đơn đã được chỉnh sửa IsInvoiceCorrected	Cờ cho biết hóa đơn đã được chỉnh sửa hoặc cập nhật sau khi tạo lần đầu hay chưa.
Mô tả Thuộc tính boolean này có giá trị true nếu hóa đơn trải qua một vòng chỉnh sửa, được xác định khi nhật ký sự kiện có hoạt động 'Invoice Corrected'. Cờ này đánh dấu các trường hợp phải làm lại ở bước lập hóa đơn. Đây là dữ liệu đầu vào quan trọng cho dashboard 'Invoice Accuracy & Rework Analysis' và KPI 'Invoice Rework Rate'. Thuộc tính này giúp định lượng mức độ sai sót khi lập hóa đơn và phân tích nguyên nhân gốc rễ khiến hóa đơn cần chỉnh sửa, từ đó giảm công việc thủ công và chậm trễ thanh toán. Vì sao điều này quan trọng Xác định các trường hợp phải làm lại hóa đơn. Đây là dấu hiệu quan trọng cho thấy quy trình kém hiệu quả, dữ liệu có vấn đề về chất lượng và khoản thanh toán có thể bị chậm. Lấy dữ liệu ở đâu Đây là trường được tính toán. Thông thường, trường này có giá trị true nếu nhật ký sự kiện của một trường hợp có hoạt động 'Invoice Corrected'. Ví dụ falsetrue
	Lần cập nhật dữ liệu gần nhất LastUpdateDate	Dấu thời gian cho biết lần gần nhất dữ liệu của sự kiện này được làm mới từ hệ thống nguồn.
Mô tả Thuộc tính này ghi lại thời điểm dữ liệu được trích xuất hoặc cập nhật lần cuối trong tập dữ liệu process mining. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến mức nào. Thông tin này giúp người dùng hiểu phân tích quy trình phản ánh tình hình hiện tại ra sao. Thuộc tính cũng giúp đặt kỳ vọng về độ mới của dữ liệu và thiết lập, theo dõi lịch làm mới dữ liệu. Vì sao điều này quan trọng Cho biết độ mới của dữ liệu để người dùng biết phân tích quy trình đã được cập nhật đến thời điểm nào. Lấy dữ liệu ở đâu Giá trị này được tạo và gắn vào tập dữ liệu trong mỗi chu kỳ trích xuất và chuyển đổi dữ liệu. Ví dụ 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Loại đơn hàng OrderType	Phân loại đơn hàng bán, chẳng hạn “Đơn hàng tiêu chuẩn” hoặc “Đơn hàng trả lại”.
Mô tả Loại đơn hàng dùng để phân nhóm đơn hàng bán theo mục đích kinh doanh. Các loại phổ biến gồm đơn hàng bán tiêu chuẩn, đơn dịch vụ, yêu cầu cho phép trả lại hàng (RMA) và đơn hàng nội bộ. Phân tích quy trình theo loại đơn hàng rất quan trọng vì mỗi loại thường có luồng quy trình và mục tiêu hiệu suất riêng. Cách phân nhóm này giúp nhận biết những khác biệt quy trình có chủ đích và được dự kiến, tránh nhầm chúng với sai lệch. Vì sao điều này quan trọng Cho phép phân nhóm các luồng quy trình hợp lệ nhưng khác nhau, chẳng hạn đơn hàng tiêu chuẩn và hàng trả lại, để đảm bảo phân tích công bằng và chính xác. Lấy dữ liệu ở đâu Thường có dưới dạng một trường trong bảng phần đầu đơn hàng bán của Oracle Fusion. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ Đơn hàng bán tiêu chuẩnCho phép trả hàngĐơn hàng dịch vụ
	Phương thức vận chuyển ShippingMethod	Phương thức hoặc đơn vị vận chuyển dùng để giao hàng cho khách.
Mô tả Thuộc tính này cho biết đơn vị vận chuyển hoặc cấp độ dịch vụ logistics được dùng để giao hàng, chẳng hạn “Vận tải đường bộ”, “Chuyển phát nhanh đường hàng không” hoặc “Giao hàng nội thành”. Thông tin này rất cần thiết cho dashboard “Tuân thủ giao hàng theo phương thức vận chuyển”. Dashboard giúp so sánh hiệu suất giao hàng đúng hạn và chi phí vận chuyển giữa các phương thức, đơn vị vận chuyển, từ đó hỗ trợ tối ưu chiến lược logistics và lựa chọn nhà cung cấp. Vì sao điều này quan trọng Hỗ trợ trực tiếp việc phân tích logistics bằng cách so sánh hiệu suất của các đơn vị và phương thức vận chuyển. Lấy dữ liệu ở đâu Có trong các bảng vận chuyển và thực hiện đơn hàng của Oracle Fusion. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ FedEx GroundUPS Next Day AirDHL International
	Quốc gia của khách hàng CustomerCountry	Quốc gia nơi khách hàng sinh sống hoặc hoạt động.
Mô tả Thuộc tính này cho biết quốc gia lấy từ địa chỉ giao hàng hoặc địa chỉ thanh toán của khách hàng. Đây là chiều phân tích quan trọng theo khu vực địa lý. Phân nhóm quy trình theo quốc gia có thể cho thấy khác biệt giữa các khu vực về hiệu suất quy trình, thời gian chu trình hoặc hành vi thanh toán. Thông tin này hữu ích để hiểu tác động của quy định địa phương, thách thức logistics và điều kiện thị trường đến quy trình từ đơn hàng đến thu tiền. Vì sao điều này quan trọng Hỗ trợ phân tích theo khu vực địa lý để xác định khác biệt giữa các vùng về hiệu quả quy trình, tuân thủ và hành vi khách hàng. Lấy dữ liệu ở đâu Lấy từ các bảng dữ liệu khách hàng chính (HZ_LOCATIONS, HZ_PARTY_SITES) được liên kết với đơn hàng bán. Ví dụ USAĐứcNhật Bản
	Số hóa đơn InvoiceNumber	Mã định danh duy nhất của hóa đơn khách hàng.
Mô tả Thuộc tính này là số duy nhất được gán cho hóa đơn tạo từ đơn hàng bán. Số này liên kết hoạt động bán hàng và thực hiện đơn hàng với khâu quyết toán tài chính trong quy trình. Đơn hàng bán là Case ID chính, nhưng Số hóa đơn rất quan trọng khi phân tích các quy trình con về lập hóa đơn và thanh toán. Thuộc tính này cần thiết để theo dõi việc chỉnh sửa hóa đơn, tranh chấp và trạng thái thanh toán, đồng thời hỗ trợ các dashboard như “Phân tích độ chính xác và việc làm lại hóa đơn”. Vì sao điều này quan trọng Tạo liên kết quan trọng đến quy trình khoản phải thu và cần thiết để phân tích việc làm lại hóa đơn cũng như chu kỳ thanh toán. Lấy dữ liệu ở đâu Có trong các bảng giao dịch khoản phải thu của Oracle Fusion, chẳng hạn RA_CUSTOMER_TRX_ALL. Ví dụ INV-93485INV-93486INV-93487
	Tên sản phẩm ProductName	Tên sản phẩm hoặc dịch vụ được bán.
Mô tả Thuộc tính này xác định mặt hàng trên dòng đơn hàng bán. Nếu đơn hàng có nhiều dòng, bạn có thể phân tích hồ sơ ở cấp mặt hàng hoặc tổng hợp thuộc tính này ở cấp phần đầu đơn hàng. Phân tích theo sản phẩm giúp xác định sản phẩm nào gắn với luồng quy trình phức tạp hoặc có vấn đề, chẳng hạn thường xuyên giao hàng trễ hoặc gặp vấn đề thanh toán. Thông tin này hỗ trợ việc quản lý sản phẩm và hoạch định chuỗi cung ứng. Vì sao điều này quan trọng Hỗ trợ phân tích hiệu suất quy trình theo từng sản phẩm, làm rõ mặt hàng có thể cần quy trình thực hiện hoặc lập hóa đơn phức tạp. Lấy dữ liệu ở đâu Lấy từ các bảng dòng đơn hàng bán và kết hợp với bảng dữ liệu sản phẩm chính. Tham khảo tài liệu Oracle Fusion Financials. Ví dụ Standard Widget X1Gói dịch vụ cao cấpComponent Y2-B
	Thanh toán trễ IsLatePayment	Cờ được tính là true nếu khoản thanh toán được nhận sau ngày đến hạn.
Mô tả Thuộc tính dạng đúng/sai này được xác định bằng cách so sánh ngày thực tế nhận thanh toán với PaymentDueDate. Thuộc tính cho biết rõ hóa đơn đã được thanh toán đúng hạn hay chưa. Thuộc tính này được dùng để tính KPI “Tỷ lệ thanh toán đúng hạn”. Bạn có thể dễ dàng phân nhóm khoản thanh toán đúng hạn và trễ hạn để phân tích đặc điểm của khách hàng thường thanh toán trễ, nguyên nhân phổ biến gây chậm trễ và ảnh hưởng tài chính đến vốn lưu động. Vì sao điều này quan trọng Đo lường trực tiếp hiệu quả thu hồi tiền thanh toán và giúp phân tích các khoản thanh toán quá hạn dễ dàng hơn. Lấy dữ liệu ở đâu Đây là trường được tính toán theo logic: PaymentReceivedDate > PaymentDueDate. Ví dụ falsetrue

Bắt buộc Nên có Không bắt buộc

Các hoạt động trong quy trình xử lý đơn hàng đến thu tiền

Đây là những bước và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá quy trình và đánh giá hiệu suất chính xác.

6 Nên có 8 Không bắt buộc

	Hoạt động	Mô tả
	Đã đóng đơn hàng	Hoạt động cuối cùng trong quy trình, cho biết tất cả các dòng của đơn hàng bán đã được thực hiện, lập hóa đơn và đóng. Trạng thái phần đầu đơn hàng được cập nhật thành “Closed”.
Vì sao điều này quan trọng Hoạt động này đánh dấu đơn hàng bán đã hoàn tất thành công. Đây là dữ liệu cần thiết để tính thời gian quy trình từ đầu đến cuối và phát hiện các đơn hàng tồn đọng không bao giờ được đóng. Lấy dữ liệu ở đâu Có thể suy ra sự kiện từ lúc trạng thái phần đầu đơn hàng bán chuyển thành “Closed” trong bảng DOO_HEADERS_ALL. Dấu thời gian của lần đổi trạng thái cuối cùng là thời điểm diễn ra sự kiện. Thu thập Lấy dấu thời gian khi trạng thái phần đầu đơn hàng bán chuyển thành “Closed”. Loại sự kiện inferred
	Đã gửi hàng	Hoạt động này đánh dấu thời điểm hàng rời kho và đang trên đường đến khách hàng. Sự kiện được ghi nhận khi giao dịch xác nhận gửi hàng được xử lý trong Oracle Shipping.
Vì sao điều này quan trọng Đây là mốc quan trọng, đánh dấu phần hoàn tất đơn hàng đã kết thúc và kích hoạt việc lập hóa đơn. Mốc này cần thiết để đo tỷ lệ gửi hàng đúng hạn và thời gian giao hàng. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ ràng trong Oracle Shipping Execution. Giao dịch xác nhận gửi hàng tạo bản ghi trong các bảng vận chuyển như WSH_DELIVERY_DETAILS, kèm theo ngày gửi hàng. Thu thập Lấy từ dấu thời gian 'actual ship date' trong bản ghi chi tiết giao hàng gắn với dòng đơn hàng. Loại sự kiện explicit
	Đã nhận thanh toán	Hoạt động này cho biết khách hàng đã thanh toán và khoản tiền đã được ghi nhận cho hóa đơn trong Accounts Receivable. Sự kiện được ghi lại khi khoản thu tiền mặt được hạch toán.
Vì sao điều này quan trọng Đây là mốc quan trọng để đo “Tổng thời gian chu trình từ đơn hàng đến thu tiền” và “Tỷ lệ thanh toán đúng hạn”. Mốc này đánh dấu thời điểm doanh thu bán hàng chuyển thành tiền mặt. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ ràng trong Oracle Accounts Receivable. Sự kiện xuất hiện trong các bảng thu tiền mặt như AR_RECEIVABLE_APPLICATIONS_ALL khi khoản thu được ghi nhận cho hóa đơn. Thu thập Lấy dấu thời gian “apply date” từ bản ghi áp dụng khoản thu tiền mặt trong AR. Loại sự kiện explicit
	Đã tạo đơn hàng bán	Hoạt động này đánh dấu thời điểm bắt đầu quy trình đơn hàng bán, khi đơn hàng mới được nhập vào Oracle Fusion. Sự kiện thường được ghi nhận rõ ràng khi người dùng lưu bản ghi đơn hàng mới trong mô-đun Order Management.
Vì sao điều này quan trọng Là điểm bắt đầu quy trình, hoạt động này rất cần thiết để đo thời gian xử lý toàn bộ chu kỳ Order to Cash và phân tích số lượng đơn hàng tiếp nhận. Lấy dữ liệu ở đâu Sự kiện được ghi nhận rõ ràng khi tạo bản ghi đơn hàng bán trong Order Management Cloud. Tìm dấu thời gian tạo trong bảng DOO_HEADERS_ALL. Thu thập Lấy từ dấu thời gian tạo bản ghi tiêu đề đơn hàng bán. Loại sự kiện explicit
	Đã tạo hóa đơn	Hoạt động này ghi nhận việc tạo hóa đơn cho khách hàng trong mô-đun Accounts Receivable, thường được kích hoạt khi xác nhận gửi hàng. Hệ thống tạo bản ghi hóa đơn với số hóa đơn và ngày tạo riêng.
Vì sao điều này quan trọng Đánh dấu thời điểm chính thức bắt đầu chu kỳ thu tiền. Đây là cơ sở để đo 'Thời gian từ hóa đơn đến thanh toán' và hiệu quả dòng tiền tổng thể. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ ràng trong Oracle Accounts Receivable (AR). Bản ghi hóa đơn được tạo trong bảng RA_CUSTOMER_TRX_ALL cùng với ngày giao dịch. Thu thập Lấy từ ngày tạo giao dịch hóa đơn trong mô-đun AR. Loại sự kiện explicit
	Đã xác nhận đơn hàng	Mốc quan trọng này cho biết đơn hàng bán đã vượt qua các bước kiểm tra ban đầu, bao gồm phê duyệt tín dụng, và sẵn sàng được thực hiện. Sự kiện thường được suy ra khi trạng thái đơn hàng chuyển sang trạng thái như 'Đang chờ giao hàng' hoặc 'Đã lên lịch'.
Vì sao điều này quan trọng Hoạt động này là mốc quan trọng để tính 'Thời gian xác nhận đơn hàng trung bình', đồng thời đánh dấu thời điểm chuyển giao từ khâu nhập đơn sang khâu hoàn tất đơn hàng. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái của tiêu đề hoặc dòng đơn hàng bán sang giá trị cho biết đơn hàng đã sẵn sàng được thực hiện, chẳng hạn như 'Đang chờ giao hàng'. Kiểm tra các cột trạng thái trong DOO_HEADERS_ALL hoặc DOO_FULFILL_LINES_ALL. Thu thập Lấy từ dấu thời gian khi trạng thái đơn hàng chuyển sang trạng thái đã xác nhận hoặc đã lên lịch. Loại sự kiện inferred
	Đã áp dụng giữ đơn hàng do tín dụng	Hoạt động này xảy ra khi đơn hàng bán bị giữ tự động hoặc thủ công do kiểm tra tín dụng không đạt hoặc có vấn đề khác liên quan đến tín dụng. Hệ thống thường ghi nhận sự kiện này khi trạng thái giữ đơn hàng thay đổi.
Vì sao điều này quan trọng Theo dõi các trường hợp giữ đơn hàng do tín dụng rất quan trọng để xác định nguyên nhân chậm xử lý và đo hiệu quả của quy trình gỡ chặn tín dụng. Lấy dữ liệu ở đâu Suy ra từ việc áp dụng trạng thái giữ cho đơn hàng bán. Thông tin này thường được ghi trong các bảng liên quan đến trạng thái giữ, chẳng hạn như DOO_HOLDS_ALL, và liên kết với đơn hàng bán. Thu thập Suy ra từ bản ghi mới trong bảng giữ đơn hàng có loại giữ 'Credit'. Loại sự kiện inferred
	Đã điều chỉnh hóa đơn	Xảy ra khi hóa đơn đã tạo được chỉnh sửa, phát hành lại hoặc ghi có do sai sót hay tranh chấp với khách hàng. Thường có thể nhận biết qua việc tạo giấy báo có hoặc phiên bản mới của hóa đơn.
Vì sao điều này quan trọng Theo dõi các lần chỉnh sửa hóa đơn là yếu tố then chốt để tính KPI “Tỷ lệ hóa đơn phải làm lại”. KPI này cho thấy vấn đề trong quy trình lập hóa đơn có thể làm chậm thanh toán và tăng chi phí hành chính. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ việc tạo giấy báo có liên kết với hóa đơn gốc hoặc tạo phiên bản tiếp theo của cùng hóa đơn trong bảng RA_CUSTOMER_TRX_ALL. Thu thập Xác định các giấy báo có hoặc hóa đơn có tham chiếu đến giao dịch hóa đơn trước đó. Loại sự kiện inferred
	Đã đóng dòng đơn hàng	Cho biết một dòng đơn hàng bán đã được đóng hoàn toàn, nghĩa là hàng đã giao đủ, hóa đơn đã lập và không còn giao dịch nào khác dự kiến phát sinh. Hệ thống cập nhật trạng thái dòng thành “Closed”.
Vì sao điều này quan trọng Đóng dòng đơn hàng nghĩa là đã hoàn tất mọi nghĩa vụ theo hợp đồng đối với mặt hàng đó. Phân tích hoạt động này giúp phát hiện các đơn hàng vẫn mở dù đã hoàn tất giao hàng và thanh toán từ lâu. Lấy dữ liệu ở đâu Có thể suy ra sự kiện từ lúc trạng thái dòng thực hiện đơn hàng chuyển thành “Closed” trong bảng DOO_FULFILL_LINES_ALL. Dấu thời gian thay đổi trạng thái là thời điểm diễn ra sự kiện. Thu thập Lấy dấu thời gian khi trạng thái dòng thực hiện đơn hàng chuyển thành “Closed”. Loại sự kiện inferred
	Đã giữ chỗ hàng tồn kho	Hoạt động này ghi nhận việc phân bổ hoặc giữ chỗ hàng tồn kho thực tế để thực hiện dòng đơn hàng bán. Hệ thống dành riêng lượng hàng cụ thể để đảm bảo có sẵn khi đơn hàng sẵn sàng được lấy.
Vì sao điều này quan trọng Theo dõi hoạt động này giúp phân tích KPI 'Thời gian phân bổ hàng tồn kho' và xác định chậm trễ giữa lúc xác nhận đơn hàng với lúc giữ được hàng. Lấy dữ liệu ở đâu Sự kiện này thường được ghi nhận trong các mô-đun quản lý hàng tồn kho hoặc thực hiện chuỗi cung ứng. Có thể suy ra sự kiện từ cập nhật trạng thái trên dòng hoàn tất đơn hàng, cho biết hàng tồn kho đã được xác định cụ thể hoặc giữ chỗ. Thu thập Suy ra từ thay đổi trạng thái của dòng hoàn tất đơn hàng liên quan đến việc giữ chỗ hàng tồn kho hoặc lên lịch. Loại sự kiện inferred
	Đã hủy đơn hàng	Cho biết đơn hàng bán bị hủy trước khi giao hàng đầy đủ. Việc này có thể xảy ra vì nhiều lý do và khiến trạng thái cuối cùng chuyển thành “Cancelled”.
Vì sao điều này quan trọng Đây là một nhánh ngoại lệ quan trọng. Phân tích đơn hàng bị hủy giúp tìm nguyên nhân gốc rễ, chẳng hạn như hết hàng, vấn đề về giá hoặc khách hàng đổi ý, từ đó xác định hướng cải tiến quy trình. Lấy dữ liệu ở đâu Có thể suy ra sự kiện từ lúc trạng thái phần đầu hoặc dòng đơn hàng bán chuyển thành “Cancelled”. Dấu thời gian thay đổi trạng thái được dùng để ghi nhận sự kiện. Thu thập Lấy dấu thời gian khi trạng thái phần đầu hoặc dòng đơn hàng chuyển thành “Cancelled”. Loại sự kiện inferred
	Đã lấy hàng	Hoạt động này ghi nhận việc lấy hàng thực tế trong kho để thực hiện đơn hàng. Đây là bước quan trọng trong quy trình logistics và thường được ghi lại trong mô-đun quản lý kho hoặc vận chuyển.
Vì sao điều này quan trọng Hoạt động này giúp bạn theo dõi vận hành kho. Chậm trễ giữa lúc giữ chỗ hàng tồn kho và lúc lấy hàng có thể cho thấy điểm nghẽn về tài nguyên hoặc quy trình trong kho. Lấy dữ liệu ở đâu Sự kiện được ghi nhận trong các mô-đun Oracle Fusion Cloud SCM (Supply Chain Management). Có thể suy ra sự kiện từ thay đổi trạng thái của đợt lấy hàng hoặc phiếu lấy hàng gắn với dòng đơn hàng bán. Thu thập Suy ra từ dấu thời gian hoàn tất giao dịch lấy hàng trong các mô-đun SCM. Loại sự kiện inferred
	Đã thực hiện kiểm tra tín dụng	Hoạt động này ghi nhận việc kiểm tra tài khoản khách hàng để đánh giá khả năng tín dụng. Đây thường là bước tự động hoặc thủ công trong quy trình xử lý đơn hàng. Hệ thống thường ghi nhận khi bước này hoàn tất thông qua cập nhật trạng thái hoặc tác vụ đã hoàn thành.
Vì sao điều này quan trọng Phân tích thời gian kiểm tra tín dụng giúp xác định điểm nghẽn trong khâu phê duyệt đơn hàng. Đây là dữ liệu quan trọng để tính KPI 'Thời gian từ kiểm tra tín dụng đến xác nhận'. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ thay đổi trạng thái đơn hàng bán, chẳng hạn như chuyển sang trạng thái 'Đang chờ phê duyệt tín dụng', hoặc từ nhật ký sự kiện cụ thể trong chức năng quản lý tín dụng. Thu thập Suy ra từ thay đổi trạng thái đơn hàng hoặc dấu thời gian gắn với các tác vụ xét duyệt tín dụng. Loại sự kiện inferred
	Hàng hóa đã giao	Cho biết khách hàng đã nhận được lô hàng. Thông tin này thường đến từ đơn vị vận chuyển bên ngoài và được cập nhật vào Oracle Fusion. Ngoài ra, có thể suy ra thời điểm giao hàng dựa trên thời gian vận chuyển tiêu chuẩn tính từ ngày gửi hàng.
Vì sao điều này quan trọng Hoạt động này rất quan trọng để tính KPI 'Tỷ lệ giao hàng đúng hạn' và đo chính xác mức dịch vụ khách hàng. Lấy dữ liệu ở đâu Đây thường không phải là sự kiện có sẵn trong Oracle. Có thể ghi nhận nếu đã tích hợp với đơn vị vận chuyển, hoặc tính bằng cách cộng thời gian vận chuyển tiêu chuẩn vào ngày "Đã gửi hàng". Cần phân tích hệ thống để xác định cách thực hiện. Thu thập Suy ra từ dữ liệu do đơn vị vận chuyển cung cấp hoặc tính dựa trên ngày gửi hàng cộng với thời gian vận chuyển trung bình. Loại sự kiện inferred

Nên có Không bắt buộc

Hướng dẫn trích xuất

Cách lấy dữ liệu từ Oracle Fusion Financials

Các bước

Mở Oracle BI Publisher: Đăng nhập vào môi trường Oracle Fusion bằng tài khoản có quyền BI Administrator hoặc BI Author. Mở menu Navigator, vào Tools > Reports and Analytics. Nhấp 'Browse Catalog' để mở Business Intelligence Catalog.
Tạo Data Model mới: Trong BI Catalog, mở thư mục phù hợp, chẳng hạn Shared Folders > Custom. Nhấp menu thả xuống 'New' rồi chọn 'Data Model'.
Tạo bộ dữ liệu từ truy vấn SQL: Trong trình chỉnh sửa Data Model, nhấp biểu tượng '+' để tạo bộ dữ liệu mới rồi chọn 'SQL Query'. Hộp thoại sẽ xuất hiện. Đặt tên cho bộ dữ liệu, chẳng hạn 'OrderToCash_EventLog', chọn 'Oracle BI EE' làm Data Source và chọn 'Standard SQL' làm loại SQL.
Nhập 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 rồi dán vào vùng nhập SQL Query. Truy vấn có các tham số ngày bắt đầu và ngày kết thúc (:p_start_date và :p_end_date). BI Publisher sẽ tự nhận diện các tham số này.
Cấu hình thuộc tính Data Model: Sau khi dán truy vấn, nhấp 'OK'. Trong khung bên trái của trình chỉnh sửa Data Model, mở phần 'Properties'. Đảm bảo đã chọn 'Include Parameter Tags'. Nếu muốn, bạn cũng có thể đặt giá trị mặc định cho các tham số ngày.
Xem và lưu Data Model: Nhấp thẻ 'Data'. Có thể bạn sẽ được yêu cầu nhập giá trị cho các tham số ngày. Hãy nhập khoảng ngày ngắn để kiểm tra. Nhấp 'View' để xem dữ liệu mẫu. Nếu dữ liệu hiển thị chính xác, nhấp biểu tượng lưu và đặt tên dễ nhận biết cho Data Model, chẳng hạn 'OrderToCash_EventLog_DM'.
Tạo báo cáo từ Data Model: Sau khi lưu Data Model, nhấp nút 'Create Report' ở góc trên bên phải. Trình hướng dẫn tạo báo cáo sẽ mở ra.
Cấu hình báo cáo: Trong trình hướng dẫn, chọn 'Use Data Model'. Trình hướng dẫn sẽ giúp bạn thiết lập bố cục. Để xuất CSV đơn giản, bạn có thể chọn bố cục 'Table'. Kéo tất cả các cột vào bảng. Nhấp 'Next', rồi bỏ chọn 'Show Grand Totals Row'. Nhấp 'Finish' để lưu báo cáo. Đặt tên cho báo cáo, chẳng hạn 'OrderToCash_EventLog_Report'.
Chạy báo cáo: Mở báo cáo vừa tạo. Bạn sẽ được yêu cầu nhập ngày bắt đầu và ngày kết thúc để trích xuất dữ liệu. Nhập khoảng ngày cần lấy.
Xuất dữ liệu: Sau khi báo cáo chạy xong, nhấp menu thả xuống 'View' và chọn một tùy chọn khác, chẳng hạn 'View Report'. Sau đó, tìm liên kết hoặc biểu tượng 'Export' và chọn 'CSV' làm định dạng xuất. Thao tác này sẽ tải xuống tệp nhật ký sự kiện.
Chuẩn bị tải lên: Mở tệp CSV vừa tải xuống. Kiểm tra tiêu đề cột có khớp với các thuộc tính bắt buộc không: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate và IsAutomated. Tệp đã sẵn sàng để tải lên công cụ process mining.

Cấu hình

Quyền người dùng: Bạn cần có vai trò cho phép tạo Data Model và báo cáo trong BI Publisher, chẳng hạn 'BI Administrator' hoặc 'BI Author'.
Nguồn dữ liệu: Truy vấn được thiết kế cho nguồn dữ liệu ứng dụng 'Oracle BI EE' tiêu chuẩn, kết nối với cơ sở dữ liệu giao dịch (Fusion Apps). Thông thường, bạn không cần cấu hình gì thêm.
Tham số khoảng ngày: Truy vấn dùng hai tham số :p_start_date và :p_end_date để lọc dữ liệu. Bạn nên trích xuất theo từng đợt vừa phải, chẳng hạn mỗi lần từ 3 đến 6 tháng, để tránh báo cáo hết thời gian chờ hoặc gặp vấn đề về hiệu suất.
Lọc theo đơn vị kinh doanh: Để giới hạn phạm vi trích xuất, bạn có thể thêm mệnh đề WHERE vào CTE BaseOrders trong truy vấn để lọc theo mã đơn vị kinh doanh cụ thể, chẳng hạn AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
Lọc theo loại đơn hàng: Bạn cũng có thể lọc theo loại đơn hàng bán cụ thể bằng cách thêm điều kiện cho dhead.SOURCE_ORDER_TYPE_CODE trong CTE BaseOrders.
Hiệu suất: Với tập dữ liệu rất lớn, kéo dài nhiều năm, cách dùng một truy vấn duy nhất có thể chậm. Hãy cân nhắc chạy vào giờ thấp điểm hoặc chia dữ liệu thành các đợt nhỏ theo tháng. Đảm bảo không chọn thuộc tính 'Enable SQL Pruning' trong Data Model, vì thuộc tính này có thể ảnh hưởng đến các truy vấn UNION phức tạp.

Truy vấn mẫu sql

WITH BaseOrders AS (
    SELECT
        dhead.HEADER_ID,
        dhead.ORDER_NUMBER AS SalesOrder,
        dhead.CREATION_DATE,
        dhead.CREATED_BY,
        (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
        dhead.SUBMITTING_BU_ID,
        dhead.AMOUNT AS SalesOrderTotalAmount,
        hp_sold.PARTY_NAME AS CustomerName,
        dhead.SALES_CHANNEL_CODE AS SalesChannel,
        dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
    FROM
        DOO_HEADERS_ALL dhead
    JOIN
        DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
    JOIN
        HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
    JOIN
        HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
    WHERE
        dhead.OBJECT_VERSION_NUMBER = 1
        AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
        AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
    bo.SalesOrder,
    'Sales Order Created' AS ActivityName,
    bo.CREATION_DATE AS EventTime,
    bo.UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo

UNION ALL

-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
    bo.SalesOrder,
    'Credit Check Performed' AS ActivityName,
    dha.RELEASED_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL

UNION ALL

-- 3. Credit Hold Applied
SELECT
    bo.SalesOrder,
    'Credit Hold Applied' AS ActivityName,
    dha.APPLIED_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL

UNION ALL

-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
    bo.SalesOrder,
    'Order Confirmed' AS ActivityName,
    dfl.STATUS_CHANGE_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'

UNION ALL

-- 5. Inventory Reserved
SELECT 
    bo.SalesOrder,
    'Inventory Reserved' AS ActivityName,
    irl.LAST_UPDATE_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry

UNION ALL

-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
    bo.SalesOrder,
    'Goods Picked' AS ActivityName,
    wdd.LAST_UPDATE_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked

UNION ALL

-- 7. Goods Shipped
SELECT
    bo.SalesOrder,
    'Goods Shipped' AS ActivityName,
    wnd.INITIAL_PICKUP_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped

UNION ALL

-- 8. Goods Delivered
SELECT
    bo.SalesOrder,
    'Goods Delivered' AS ActivityName,
    wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL

UNION ALL

-- 9. Invoice Created
SELECT
    bo.SalesOrder,
    'Invoice Created' AS ActivityName,
    rct.TRX_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    aps.DUE_DATE AS PaymentDueDate,
    CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'

UNION ALL

-- 10. Invoice Corrected (Credit Memo)
SELECT
    bo.SalesOrder,
    'Invoice Corrected' AS ActivityName,
    rct_cm.TRX_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'

UNION ALL

-- 11. Payment Received
SELECT
    bo.SalesOrder,
    'Payment Received' AS ActivityName,
    araa.APPLY_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'

UNION ALL

-- 12. Order Line Closed
SELECT
    bo.SalesOrder,
    'Order Line Closed' AS ActivityName,
    dfl.LAST_UPDATE_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'

UNION ALL

-- 13. Order Closed
SELECT
    bo.SalesOrder,
    'Order Closed' AS ActivityName,
    dhead.LAST_UPDATE_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'

UNION ALL

-- 14. Order Cancelled
SELECT
    bo.SalesOrder,
    'Order Cancelled' AS ActivityName,
    dhead.LAST_UPDATE_DATE AS EventTime,
    (SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
    bo.SalesOrderTotalAmount,
    bo.CustomerName,
    bo.SalesChannel,
    bo.RequestedDeliveryDate,
    NULL AS ActualDeliveryDate,
    NULL AS PaymentDueDate,
    CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED'

Các bước

Mở BICC Console: Đăng nhập vào Oracle Fusion Applications bằng tài khoản có vai trò BICC_ADMINISTRATOR. Vào Tools rồi chọn Business Intelligence Cloud Connector trong menu.
Tạo Offering mới: Trong BICC Console, nhấp Configure External Storage để thiết lập nơi lưu trữ đích. Bạn có thể chọn Oracle Universal Content Management (UCM) hoặc vùng lưu trữ đối tượng OCI. Kiểm tra thông tin kết nối và thông tin xác thực.
Tạo tác vụ trích xuất mới: Mở phần Manage Extract Jobs. Nhấp biểu tượng + để tạo tác vụ mới. Đặt tên dễ nhận biết, chẳng hạn ProcessMind_O2C_SalesOrder_Extract.
Chọn Data Store (PVO): Trong cấu hình tác vụ, tìm và thêm các Public View Object (PVO) cần thiết để ghi nhận vòng đời đơn hàng bán. Bạn cần thêm nhiều PVO, gồm FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice và FscmTopModelAM.ArTopAM.CashReceiptApplication.
Chọn cột cho từng PVO: Với mỗi PVO đã chọn, nhấp menu Actions rồi chọn Select Columns. Chọn kỹ các cột cần thiết để tạo nhật ký sự kiện, chẳng hạn HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate và mã người dùng. Xem danh sách truy vấn để biết chi tiết các cột cần lấy từ từng PVO.
Thêm bộ lọc cho các lần tải tăng dần: Để kiểm soát lượng dữ liệu, hãy lọc từng PVO theo cột LastUpdateDate. Trong lần chạy đầu tiên, bạn có thể chọn khoảng ngày rộng. Với các lần chạy theo lịch sau đó, hãy cấu hình bộ lọc để chỉ trích xuất những bản ghi được cập nhật kể từ lần chạy gần nhất.
Lên lịch trích xuất: Mở phần Manage Schedule và tạo lịch mới cho tác vụ. Nên chạy vào giờ thấp điểm, chẳng hạn ban đêm mỗi ngày, để giảm ảnh hưởng đến hiệu suất hệ thống.
Gửi và theo dõi tác vụ: Sau khi cấu hình xong, gửi tác vụ. Bạn có thể theo dõi tiến độ trên màn hình Manage Extract Jobs. Khi tác vụ chạy thành công, các tệp dữ liệu sẽ có trong vị trí lưu trữ đám mây đã cấu hình, ở định dạng CSV nén.
Chuyển dữ liệu thô thành nhật ký sự kiện: Tải các tệp CSV đã trích xuất xuống. BICC cung cấp dữ liệu bảng thô, không phải nhật ký sự kiện đã định dạng. Bạn cần dùng công cụ bên ngoài, chẳng hạn Python, tập lệnh cơ sở dữ liệu hoặc nền tảng ETL, để xử lý các tệp này. Các bước gồm:
- Kết hợp dữ liệu từ nhiều tệp, chẳng hạn liên kết dữ liệu hóa đơn với phần đầu đơn hàng bán.
- Chuyển các cột ngày thành các dòng hoạt động riêng. Ví dụ, từ tệp FscmTopModelAM.DooTopAM.Header, tạo một dòng Sales Order Created dùng CreationDate và một dòng Order Closed dùng ClosedDate.
- Ánh xạ mã trạng thái hoặc cờ thành các hoạt động cụ thể như Order Confirmed hoặc Order Cancelled.
- Gộp dữ liệu đã chuyển đổi vào một tệp duy nhất với các cột bắt buộc: SalesOrder, ActivityName và EventTime.
Định dạng để tải lên: Đảm bảo tệp cuối cùng là một tệp CSV, có các cột khớp với thuộc tính bắt buộc và được đề xuất. Tệp đã sẵn sàng để tải lên ProcessMind.

Cấu hình

Chọn PVO: Độ chính xác của nhật ký sự kiện phụ thuộc hoàn toàn vào việc chọn đúng PVO. Các PVO quan trọng gồm FscmTopModelAM.DooTopAM.Header (ghi nhận việc tạo và đóng đơn hàng), FscmTopModelAM.ScmTopAM.ShipmentLine (ghi nhận sự kiện giao hàng) và FscmTopModelAM.ArTopAM.ReceivableInvoice (ghi nhận việc lập hóa đơn).
Trích xuất tăng dần: Luôn dùng bộ lọc LastUpdateDate cho các lần trích xuất định kỳ. Đây là bước quan trọng để đảm bảo hiệu suất và tránh trích xuất lặp lại cùng một tập dữ liệu nhiều gigabyte. Lần tải đầy đủ đầu tiên tạo dữ liệu nền, các lần sau chỉ lấy phần thay đổi.
Khoảng ngày: Với lần tải dữ liệu lịch sử đầu tiên, hãy chọn khoảng thời gian đại diện, chẳng hạn dữ liệu từ 3 đến 6 tháng gần nhất, để cân bằng giữa độ đầy đủ và lượng dữ liệu có thể xử lý. Các lần chạy sau sẽ trích xuất tăng dần.
Cấu hình lưu trữ: BICC có thể xuất dữ liệu sang UCM của Oracle hoặc OCI Object Storage. Với dữ liệu số lượng lớn và để dễ tích hợp với các công cụ ETL tiếp theo, thường nên dùng OCI Object Storage.
Lên lịch tác vụ: Lên lịch trích xuất ngoài giờ làm việc để tránh ảnh hưởng đến hiệu suất của hệ thống giao dịch Oracle Fusion Financials.
Điều kiện cần: Người cấu hình tác vụ cần có vai trò BICC_ADMINISTRATOR. Bạn cũng cần thiết lập sẵn thông tin xác thực cho bộ nhớ đám mây và hiểu rõ cách chuyển đổi dữ liệu sau khi trích xuất.

Truy vấn mẫu config

# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.

# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
  - HeaderId -> SalesOrder
  - CreationDate -> EventTime (for 'Sales Order Created')
  - CreatedBy -> UserName (for 'Sales Order Created')
  - LastUpdateDate # For incremental filtering
  - StatusCode
  - SubmittedDate -> EventTime (for 'Order Confirmed')
  - SubmittedBy -> UserName (for 'Order Confirmed')
  - OrderedTotal -> SalesOrderTotalAmount
  - SoldToPartyName -> CustomerName
  - SourceSalesChannelCode -> SalesChannel
  - RequestShipDate -> RequestedDeliveryDate
  - ClosedDate -> EventTime (for 'Order Closed')
  - CanceledFlag
  - CanceledDate -> EventTime (for 'Order Cancelled')

# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
  - HeaderId -> SalesOrder
  - ActualCompletionDate -> EventTime (for 'Order Line Closed')
  - LastUpdateDate # For incremental filtering
  - LastUpdatedBy -> UserName
  - StatusName # To confirm closed status

# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
  - SourceHeaderId -> SalesOrder
  - CreationDate -> EventTime (for 'Credit Hold Applied')
  - CreatedBy -> UserName
  - HoldName # To filter for credit-related holds

# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
  - SourceHeaderNumber -> SalesOrder
  - PickedDate -> EventTime (for 'Goods Picked')
  - ShippedDate -> EventTime (for 'Goods Shipped')
  - ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
  - LastUpdateDate # For incremental filtering
  - LastUpdatedBy -> UserName

# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
  - InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
  - TrxDate -> EventTime (for 'Invoice Created')
  - CreatedBy -> UserName
  - DueDate -> PaymentDueDate
  - PreviousTrxNumber # If populated, indicates a correction
  - CreationDate # Can be used for 'Invoice Corrected' if a new record is made
  - LastUpdateDate # For incremental filtering

# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
  - AppliedCustomerTrxId # ID to link back to the invoice
  - ApplyDate -> EventTime (for 'Payment Received')
  - CreatedBy -> UserName
  - LastUpdateDate # For incremental filtering

Sẵn sàng bắt đầu?

Dùng mẫu này để đơn giản hóa việc thu thập dữ liệu và bắt đầu hành trình process mining. Bắt đầu tối ưu quy trình xử lý đơn hàng đến thu tiền ngay hôm nay.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Tối ưu quy trình xử lý đơn hàng đến thu tiền ngay hôm nay

Dễ dàng xác định điểm nghẽn và giảm 30% thời gian xử lý đơn hàng đến thu tiền.

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

Không cần thẻ tín dụng. Dùng thử miễn phí trong 14 ngày.

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Mẫu dữ liệu cho quy trình xử lý đơn hàng đến thu tiền

Các thuộc tính của quy trình xử lý đơn hàng đến thu tiền

Các hoạt động trong quy trình xử lý đơn hàng đến thu tiền

Hướng dẫn trích xuất

Báo cáo Oracle Fusion BI Publisher cho đơn hàng bán

Các bước

Cấu hình

Truy vấn mẫu sql

Dùng Oracle BICC để trích xuất hàng loạt dữ liệu đơn hàng bán

Các bước

Cấu hình

Truy vấn mẫu config

Sẵn sàng bắt đầu?

Tối ưu quy trình xử lý đơn hàng đến thu tiền ngay hôm nay