Mẫu dữ liệu Purchase to Pay - Requisition
Mẫu dữ liệu Purchase to Pay - Requisition
- Các thuộc tính nên thu thập để phân tích chi tiết
- Các 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ừ SAP S/4HANA
Thuộc tính Purchase to Pay - Requisition
| Tên | Mô tả | ||
|---|---|---|---|
| Mã yêu cầu mua hàng PurchaseRequisitionId | Mã định danh duy nhất của chứng từ yêu cầu mua hàng. | ||
| Mô tả Mã yêu cầu mua hàng là khóa chính, dùng để nhận diện duy nhất từng yêu cầu hàng hóa hoặc dịch vụ trong SAP S/4HANA. Đây là mã định danh trung tâm của từng trường hợp, liên kết mọi hoạt động và thay đổi liên quan đến một yêu cầu cụ thể, từ lúc tạo đến trạng thái cuối cùng như được phê duyệt, bị từ chối hoặc chuyển thành đơn đặt hàng. Trong process mining, thuộc tính này là nền tảng để dựng lại toàn bộ vòng đời của từng yêu cầu. Khi nhóm mọi sự kiện liên quan theo cùng một mã yêu cầu mua hàng, nhà phân tích có thể đo chính xác thời gian xử lý, theo dõi thay đổi trạng thái và phân tích các hướng xử lý khác nhau trong quy trình phê duyệt. Vì sao điều này quan trọng Đây là mã định danh trường hợp thiết yếu, kết nối mọi bước liên quan để bạn có cái nhìn đầy đủ, nhất quán về vòng đời yêu cầu mua hàng. Lấy dữ liệu ở đâu Đây là số yêu cầu mua hàng, nằm trong bảng EBAN, trường BANFN. Ví dụ 100178901001789110017892 | |||
| Tên hoạt động ActivityName | Tên hoạt động nghiệp vụ diễn ra tại một thời điểm cụ thể trong quy trình yêu cầu mua hàng. | ||
| Mô tả Tên hoạt động mô tả một sự kiện hoặc tác vụ cụ thể trong vòng đời của yêu cầu mua hàng. Các hoạt động này được xác định từ nhật ký hệ thống, chẳng hạn như chứng từ thay đổi và lịch sử workflow. Chúng thể hiện các mốc quan trọng của quy trình như 'Tạo yêu cầu mua hàng', 'Bắt đầu bước phê duyệt' hoặc 'Tạo đơn đặt hàng'. Phân tích các hoạt động này giúp trực quan hóa luồng quy trình, xác định điểm nghẽn và đo thời gian ở từng giai đoạn. Hiểu trình tự và tần suất của các hoạt động như 'Chỉnh sửa yêu cầu mua hàng' hoặc 'Từ chối yêu cầu mua hàng' là điều cần thiết để phát hiện điểm kém hiệu quả và cơ hội cải tiến. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong quy trình, làm nền tảng cho sơ đồ quy trình và giúp phân tích luồng, các biến thể cũng như điểm nghẽn. Lấy dữ liệu ở đâu Đây là thuộc tính được suy ra, thường bằng cách diễn giải dữ liệu từ các bảng chứng từ thay đổi (CDHDR, CDPOS) và nhật ký workflow (ví dụ: SWWLOGHIST). Ví dụ Tạo yêu cầu mua hàngHoàn tất bước phê duyệtPhê duyệt yêu cầu mua hàngTạo đơn đặt hàng | |||
| Thời điểm sự kiện EventTime | Ngày và giờ chính xác khi một hoạt động cụ thể diễn ra. | ||
| Mô tả Thời điểm sự kiện là dấu thời gian ghi lại lúc một hoạt động diễn ra. Dữ liệu này rất quan trọng để sắp xếp sự kiện theo trình tự thời gian trong từng trường hợp, đồng thời là cơ sở cho mọi phép tính thời lượng và hiệu suất trong process mining. Ví dụ, khoảng thời gian giữa sự kiện 'Gửi yêu cầu mua hàng để phê duyệt' và 'Phê duyệt yêu cầu mua hàng' cho biết thời gian xử lý phê duyệt. Dấu thời gian chính xác là điều cần thiết để phân tích hiệu suất quy trình, phát hiện chậm trễ và theo dõi việc đáp ứng thỏa thuận mức dịch vụ. Thuộc tính này hỗ trợ tạo dashboard để trực quan hóa thời gian xử lý, theo dõi yêu cầu bị đình trệ và so sánh hiệu suất qua các giai đoạn. Vì sao điều này quan trọng Dấu thời gian này cần thiết để sắp xếp sự kiện, tính thời gian xử lý và phân tích hiệu suất cũng như điểm nghẽn của quy trình. Lấy dữ liệu ở đâu Dấu thời gian thường lấy từ phần đầu của chứng từ thay đổi (CDHDR-UDATE, CDHDR-UTIME) hoặc nhật ký sự kiện workflow. Ví dụ 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Giá trị yêu cầu mua hàng RequisitionAmount | Tổng giá trị tiền tệ của yêu cầu mua hàng. | ||
| Mô tả Giá trị yêu cầu mua hàng là tổng chi phí ước tính của hàng hóa hoặc dịch vụ được yêu cầu. Giá trị này thường ảnh hưởng đến độ phức tạp và thời gian của quy trình phê duyệt. Yêu cầu có giá trị cao thường cần qua nhiều cấp phê duyệt hơn. Phân tích thuộc tính này giúp phân nhóm quy trình theo giá trị. Bạn có thể trả lời những câu hỏi như: 'Yêu cầu có giá trị cao có mất nhiều thời gian phê duyệt hơn không?' hoặc 'Giá trị của các yêu cầu thường bị từ chối là bao nhiêu?'. Đây là chiều phân tích quan trọng để hiểu tác động tài chính của những điểm kém hiệu quả trong quy trình. Vì sao điều này quan trọng Giúp phân nhóm quy trình theo tác động tài chính, thường liên quan đến độ phức tạp của việc phê duyệt và thời gian xử lý. Đây là thuộc tính quan trọng để phân tích quy trình theo giá trị. Lấy dữ liệu ở đâu Tổng giá trị nằm trong bảng EBAN, trường GFWERT. Giá trị ở cấp dòng nằm trong EBAN-PREIS. Ví dụ 1500.0075000.50250.75 | |||
| Loại yêu cầu mua hàng RequisitionType | Mã phân loại yêu cầu mua hàng, chẳng hạn yêu cầu hàng hóa tiêu chuẩn, dịch vụ hoặc chi phí đầu tư. | ||
| Mô tả Loại yêu cầu mua hàng, còn gọi là loại chứng từ trong SAP, là trường cấu hình quan trọng dùng để phân loại yêu cầu mua hàng. Mỗi loại có thể kích hoạt quy trình phê duyệt khác nhau, có thiết lập trường riêng và phục vụ mục đích kinh doanh khác nhau, chẳng hạn mua hàng tồn kho tiêu chuẩn, dịch vụ bên ngoài hoặc tài sản. Phân tích quy trình theo loại yêu cầu mua hàng giúp tổ chức hiểu cách xử lý từng nhóm yêu cầu. Bạn có thể so sánh hiệu suất, thời gian xử lý và các bước phê duyệt giữa các nhóm, từ đó nhận biết loại yêu cầu nào xử lý hiệu quả hơn hoặc kém hơn và xác định hướng cải tiến phù hợp. Vì sao điều này quan trọng Phân loại yêu cầu để so sánh, giúp xác định các loại yêu cầu khác nhau có luồng xử lý, điểm nghẽn hoặc thời gian xử lý khác nhau hay không. Lấy dữ liệu ở đâu Đây là trường loại chứng từ trong bảng EBAN, trường BSART. Ví dụ NBFORV | |||
| Mã người dùng UserId | Mã định danh của người tạo yêu cầu mua hàng hoặc thực hiện một hoạt động cụ thể. | ||
| Mô tả Mã người dùng xác định nhân viên hoặc người dùng hệ thống chịu trách nhiệm cho một sự kiện trong vòng đời yêu cầu mua hàng. Đó có thể là người tạo yêu cầu, quản lý phê duyệt hoặc nhân viên chỉnh sửa yêu cầu. Với các bước tự động, mã này có thể thuộc về người dùng hệ thống hoặc tài khoản chạy theo lô. Phân tích theo mã người dùng giúp hiểu hành vi của từng người, cách phân bổ khối lượng công việc và hiệu suất. Thuộc tính này giúp xác định nhu cầu đào tạo, ghi nhận người làm việc hiệu quả và bảo đảm trách nhiệm trong quy trình. Khi kết hợp với dữ liệu danh mục người dùng, thuộc tính này còn hỗ trợ phân tích hiệu suất theo phòng ban. Vì sao điều này quan trọng Hỗ trợ phân tích hiệu suất người dùng, phân bổ khối lượng công việc và mức độ tuân thủ quy trình. Thuộc tính này rất quan trọng để xác định nhu cầu đào tạo và điểm nghẽn về nguồn lực. Lấy dữ liệu ở đâu Mã người tạo nằm trong EBAN-ERNAM. Với các thay đổi tiếp theo, mã này nằm trong CDHDR-USERNAME. Thông tin phê duyệt nằm trong nhật ký workflow. Ví dụ JSMITHRROEWF-BATCH | |||
| Mã người phê duyệt ApproverId | Mã định danh của người thực hiện bước phê duyệt hoặc từ chối. | ||
| Mô tả Mã người phê duyệt xác định cụ thể người hoàn tất một hoạt động phê duyệt hoặc từ chối. Khác với mã người dùng thông thường, thuộc tính này chỉ tập trung vào người ra quyết định trong quy trình phê duyệt. Ghi nhận thông tin này là điều cần thiết để phân tích chi tiết quy trình. Thuộc tính này giúp phân tích cách phê duyệt, chẳng hạn như xác định quản lý mất nhiều thời gian để phê duyệt hoặc thường xuyên từ chối yêu cầu. Đây là dữ liệu nền tảng cho dashboard theo dõi thời gian xử lý từng bước phê duyệt và điểm nghẽn trong workflow, giúp xác định cá nhân hoặc vai trò cụ thể gây chậm trễ. Vì sao điều này quan trọng Xác định người ra quyết định ở từng bước phê duyệt, giúp phân tích chi tiết thời gian xử lý và điểm nghẽn theo từng cá nhân hoặc vai trò. Lấy dữ liệu ở đâu Thông tin này thường được trích xuất từ các bảng SAP Business Workflow như SWW_WI2OBJ và SWWLOGHIST, nơi liên kết các mục công việc với người dùng hoàn tất chúng. Ví dụ MJOHNSONCWILLIAMSLBLACK | |||
| Phòng ban Department | Phòng ban hoặc trung tâm chi phí chịu khoản chi phí của yêu cầu mua hàng. | ||
| Mô tả Thuộc tính phòng ban, thường được thể hiện bằng trung tâm chi phí trong SAP, xác định đơn vị kinh doanh chịu trách nhiệm cho mặt hàng được yêu cầu. Đây là thông tin quan trọng về tài chính và cơ cấu tổ chức, được gán ở cấp dòng yêu cầu. Trong process mining, thuộc tính này rất cần thiết để phân tích hiệu suất theo phòng ban. Thuộc tính hỗ trợ tạo dashboard so sánh các chỉ số chính như thời gian xử lý, tỷ lệ chỉnh sửa và tỷ lệ từ chối giữa các phòng ban. Nhờ đó, bạn có thể tìm ra phòng ban có cách làm hiệu quả để áp dụng ở nơi khác, cũng như phòng ban cần được đào tạo hoặc hỗ trợ thêm về quy trình. Vì sao điều này quan trọng Hỗ trợ so sánh hiệu suất giữa các đơn vị kinh doanh, làm rõ khác biệt về thời gian xử lý hoặc tỷ lệ từ chối để tìm ra cách làm hiệu quả và những điểm cần cải thiện. Lấy dữ liệu ở đâu Đây là trung tâm chi phí, thường nằm trong bảng phân bổ tài khoản EBKN, trường KOSTL. Ví dụ FIN-1001IT-2005MKT-3010 | |||
| Trạng thái yêu cầu mua hàng RequisitionStatus | Trạng thái xử lý hoặc phê duyệt hiện tại của yêu cầu mua hàng. | ||
| Mô tả Trạng thái yêu cầu mua hàng cho biết yêu cầu đang ở giai đoạn nào trong vòng đời. Trong SAP, trạng thái này thường được thể hiện bằng chỉ báo phê duyệt, cho biết yêu cầu đang bị chặn, chờ phê duyệt, được phê duyệt một phần hay đã được phê duyệt đầy đủ. Trạng thái thay đổi khi yêu cầu đi qua quy trình làm việc. Theo dõi trạng thái theo thời gian là điều cần thiết để hiểu luồng quy trình. Việc này giúp xác định yêu cầu bị mắc ở đâu và trong bao lâu. Phân tích các lần chuyển trạng thái cho thấy chi tiết quy trình phê duyệt và những biến thể của quy trình. Vì sao điều này quan trọng Cho biết trạng thái hiện tại của yêu cầu mua hàng, giúp theo dõi tiến độ, xác định điểm nghẽn và phân tích luồng quy trình. Lấy dữ liệu ở đâu Trạng thái phê duyệt thường được xác định bằng chỉ báo phê duyệt trong bảng EBAN, trường FRGZU. Ví dụ B1S | |||
| Có phải làm lại IsRework | Cờ cho biết một hoạt động có phải là công việc làm lại hay không, chẳng hạn như sửa đổi yêu cầu sau khi gửi. | ||
| Mô tả Is Rework là cờ boolean được tính toán để nhận diện các hoạt động lặp lại hoặc không tạo thêm giá trị. Một ví dụ thường gặp trong quy trình này là hoạt động 'Đã sửa đổi yêu cầu mua hàng' diễn ra sau khi yêu cầu đã được gửi phê duyệt, khiến quy trình phê duyệt phải bắt đầu lại. Thuộc tính này rất quan trọng để định lượng khối lượng công việc làm lại và ảnh hưởng của nó đến tổng thời gian xử lý. Dashboard Requisition Amendment and Rework Rate dùng cờ này để làm rõ những điểm kém hiệu quả trong quy trình. Giảm công việc làm lại thường là mục tiêu chính của các sáng kiến cải tiến quy trình, vì việc này giúp tiết kiệm trực tiếp thời gian và công sức. Vì sao điều này quan trọng Đánh dấu các hoạt động gây lãng phí công sức hoặc lặp lại, giúp đo trực tiếp khối lượng công việc làm lại và ảnh hưởng của nó đến hiệu quả quy trình. Lấy dữ liệu ở đâu Đây là thuộc tính được tính toán. Thông thường, logic sẽ đánh dấu mọi hoạt động 'Đã sửa đổi yêu cầu mua hàng' diễn ra sau hoạt động 'Đã gửi yêu cầu mua hàng để phê duyệt' đầu tiên là công việc làm lại. Ví dụ truefalse | |||
| Được tự động hóa IsAutomated | Cờ cho biết hoạt động do người dùng hệ thống thực hiện thay vì con người. | ||
| Mô tả Thuộc tính Is Automated là cờ boolean, có giá trị true nếu một hoạt động được thực hiện bởi tài khoản hệ thống hoặc tài khoản chạy theo lô, chẳng hạn như 'WF-BATCH' cho các thao tác workflow. Thuộc tính này giúp phân biệt các bước do người dùng thực hiện với các bước được tự động hóa trong quy trình. Thuộc tính này cần thiết để đo mức độ tự động hóa trong quy trình yêu cầu mua hàng và tính KPI 'Automated Approval Rate'. Bằng cách lọc các bước tự động hoặc thủ công, nhà phân tích có thể so sánh hiệu quả và tìm cơ hội tự động hóa thêm để rút ngắn thời gian xử lý, giảm công sức thủ công. Vì sao điều này quan trọng Phân biệt hoạt động do con người thực hiện với hoạt động do hệ thống xử lý. Đây là cơ sở để đo tỷ lệ tự động hóa và tìm cơ hội tự động hóa các tác vụ thủ công. Lấy dữ liệu ở đâu Đây là thuộc tính được suy ra, thường dựa trên quy tắc kiểm tra xem User ID của một sự kiện có nằm trong danh sách tài khoản hệ thống hoặc tài khoản chạy theo lô đã biết hay không. Ví dụ truefalse | |||
| Hệ thống nguồn SourceSystem | Xác định phiên bản SAP S/4HANA cụ thể mà dữ liệu được trích xuất từ đó. | ||
| Mô tả Thuộc tính hệ thống nguồn cho biết hệ thống ban đầu nơi dữ liệu quy trình được tạo ra. Trong các tổ chức có nhiều phiên bản SAP, chẳng hạn hệ thống riêng cho phát triển, kiểm thử chất lượng và vận hành, hoặc hệ thống riêng cho từng khu vực, trường này rất quan trọng đối với quản trị dữ liệu và việc hiểu đúng bối cảnh. Thuộc tính này giúp phân biệt dữ liệu từ các nguồn khác nhau, tránh gộp dữ liệu sai và hỗ trợ phân tích theo từng hệ thống. Đây là thuộc tính bắt buộc để duy trì nguồn gốc dữ liệu và bảo đảm có thể truy vết dữ liệu quy trình. Vì sao điều này quan trọng Cung cấp thông tin cần thiết về nguồn gốc và quản trị dữ liệu, đặc biệt khi có nhiều hệ thống, đồng thời giúp truy vết dữ liệu. Lấy dữ liệu ở đâu Đây thường là mã hệ thống SAP (SID), có thể lấy từ biến hệ thống hoặc bảng cấu hình. Ví dụ S4PECCS4H_PROD_01 | |||
| 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 bản ghi này được làm mới từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này ghi lại ngày giờ của lần trích xuất hoặc cập nhật dữ liệu gần nhất từ hệ thống nguồn. Đây là siêu dữ liệu quan trọng giúp xác định dữ liệu đang phân tích mới đến mức nào. Nhà phân tích và người dùng nghiệp vụ dựa vào dấu thời gian này để biết dữ liệu quy trình có phản ánh tình hình vận hành mới nhất hay không. Khi phân tích quy trình, việc biết dữ liệu được cập nhật đến thời điểm nào là điều cần thiết để đưa ra quyết định phù hợp. Thuộc tính này giúp người dùng hiểu rõ giới hạn về độ mới của dữ liệu và bảo đảm kết luận dựa trên dữ liệu cập nhật đủ mức cần thiết cho từng phân tích. Vì sao điều này quan trọng Cho biết dữ liệu mới đến mức nào, yếu tố quan trọng để tin cậy kết quả phân tích và đưa ra quyết định kinh doanh kịp thời. Lấy dữ liệu ở đâu Dấu thời gian này được tạo và thêm vào trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL). Ví dụ 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Lý do từ chối RejectionReason | Lý do được đưa ra khi yêu cầu mua hàng bị từ chối. | ||
| Mô tả Lý do từ chối giải thích vì sao người phê duyệt từ chối yêu cầu mua hàng. Các lý do có thể gồm vượt ngân sách, thông tin không chính xác, không tuân thủ chính sách hoặc trùng với yêu cầu khác. Thông tin này giúp làm rõ nguyên nhân quy trình không thành công. Phân tích lý do từ chối giúp xác định nguyên nhân gốc rễ của điểm kém hiệu quả và việc phải làm lại. Ví dụ, nếu 'Sai trung tâm chi phí' là lý do phổ biến, có thể cần đào tạo người dùng tốt hơn hoặc bổ sung bước kiểm tra trong hệ thống. Thuộc tính này là dữ liệu chính cho dashboard phân tích yêu cầu mua hàng bị từ chối và rất quan trọng để cải tiến quy trình đúng trọng tâm. Vì sao điều này quan trọng Cho biết nguyên nhân gốc rễ khiến quy trình không thành công, giúp cải tiến đúng trọng tâm để giảm việc làm lại và tăng tỷ lệ yêu cầu chính xác ngay từ lần đầu. Lấy dữ liệu ở đâu Thông tin này thường không nằm trong trường tiêu chuẩn. Có thể ghi nhận trong các phần tử vùng chứa workflow, văn bản dài gắn với yêu cầu hoặc trường tùy chỉnh. Ví dụ Vượt ngân sáchNhà cung cấp không phù hợpYêu cầu trùng lặp | |||
| Mức độ khẩn cấp UrgencyLevel | Phân loại mức độ khẩn cấp của yêu cầu mua hàng, có thể ảnh hưởng đến thứ tự ưu tiên xử lý. | ||
| Mô tả Mức độ khẩn cấp cho biết thứ tự ưu tiên của yêu cầu mua hàng. Dù không có trường tiêu chuẩn riêng cho thông tin này, một số tổ chức dùng các trường như Requirement Tracking Number để ghi nhận. Nhờ đó, người yêu cầu có thể đánh dấu nhu cầu cấp thiết cần được xử lý nhanh. Phân tích ảnh hưởng của mức độ khẩn cấp giúp đánh giá quy trình có ưu tiên đúng các yêu cầu quan trọng hay không. Dashboard Urgency Level Impact Analysis dùng thuộc tính này để so sánh thời gian xử lý và tỷ lệ phê duyệt giữa yêu cầu khẩn cấp và yêu cầu thông thường, qua đó cho biết việc ưu tiên xử lý có đạt mục tiêu hay không. Vì sao điều này quan trọng Cho phép phân tích hiệu quả quy trình đối với các yêu cầu ưu tiên cao, giúp xác định liệu các yêu cầu khẩn cấp có thực sự được xử lý nhanh hơn hay không. Lấy dữ liệu ở đâu Không có trường tiêu chuẩn về mức độ khẩn cấp. Một số công ty dùng Requirement Tracking Number (EBAN-BEDAR) cho mục đích này. Thông tin cũng có thể nằm trong trường tùy chỉnh. Ví dụ CaoTrung bìnhThấp | |||
| Ngày cần hàng RequiredByDate | Ngày người yêu cầu cần nhận hàng hóa hoặc dịch vụ. | ||
| Mô tả Ngày cần hàng, hay ngày giao hàng trong SAP, cho biết thời điểm cần hàng hóa hoặc dịch vụ trong một dòng yêu cầu. Người yêu cầu đặt ngày này làm mốc mục tiêu cho toàn bộ quy trình mua hàng. Thuộc tính này cần thiết để tính KPI 'Tỷ lệ hoàn tất yêu cầu đúng hạn'. Bằng cách so sánh ngày cần hàng với ngày phê duyệt cuối cùng hoặc ngày tạo đơn đặt hàng, tổ chức có thể đo khả năng đáp ứng mức dịch vụ nội bộ và nhu cầu kinh doanh. Phân tích các yêu cầu không đáp ứng ngày này có thể giúp phát hiện chậm trễ mang tính hệ thống trong quy trình mua hàng. Vì sao điều này quan trọng Xác định ngày mục tiêu hoàn tất yêu cầu, giúp đo tỷ lệ giao đúng hạn và mức độ đáp ứng các mức dịch vụ nội bộ. Lấy dữ liệu ở đâu Đây là ngày giao hàng, nằm ở cấp dòng trong bảng EBAN, trường LFDAT. Ví dụ 2023-11-152023-12-012024-01-20 | |||
| Số đơn đặt hàng PurchaseOrderNumber | Số của đơn đặt hàng được tạo từ yêu cầu mua hàng. | ||
| Mô tả Số đơn đặt hàng là mã định danh của chứng từ mua hàng chính thức được tạo từ một yêu cầu đã phê duyệt. Tạo đơn đặt hàng thường là kết quả cuối cùng thành công của yêu cầu, cho biết yêu cầu đã được chuyển thành đơn hàng chính thức với nhà cung cấp. Thuộc tính này rất quan trọng để đo KPI thời gian từ yêu cầu đến đơn đặt hàng và tỷ lệ chuyển đổi tổng thể. Nó liên kết quy trình yêu cầu mua hàng với các bước mua hàng tiếp theo, giúp bạn có cái nhìn xuyên suốt hơn về toàn bộ chu trình từ mua hàng đến thanh toán. Vì sao điều này quan trọng Liên kết yêu cầu mua hàng với chứng từ mua hàng tiếp theo, giúp đo tỷ lệ chuyển đổi và thời gian từ yêu cầu đến đơn đặt hàng. Lấy dữ liệu ở đâu Nằm trong bảng EBAN, trường EBELN, sau khi đơn đặt hàng được tạo từ dòng yêu cầu mua hàng. Ví dụ 450001789045000178914500017892 | |||
| Tên bước phê duyệt ApprovalStepName | Tên hoặc mô tả cụ thể của một bước phê duyệt trong workflow. | ||
| Mô tả Tên bước phê duyệt mô tả rõ một giai đoạn cụ thể trong workflow phê duyệt, chẳng hạn như 'Phê duyệt của quản lý' hoặc 'Phê duyệt của phó chủ tịch tài chính'. Tên này cụ thể hơn hoạt động chung chung như 'Đã hoàn tất bước phê duyệt'. Thuộc tính này rất quan trọng đối với các dashboard Approval Step Cycle Time và Workflow Bottleneck Analysis. Thuộc tính cho phép xem chi tiết quy trình phê duyệt, xác định chính xác giai đoạn nào gây chậm trễ nhiều nhất và công việc đang ùn lại ở đâu. Đây là thông tin cần thiết để cải tiến đúng khâu và rút gọn chuỗi phê duyệt. Vì sao điều này quan trọng Cung cấp thông tin chi tiết về từng giai đoạn phê duyệt, giúp xác định chính xác điểm nghẽn trong workflow phê duyệt nhiều cấp. Lấy dữ liệu ở đâu Thông tin này được lấy từ mô tả tác vụ workflow. Bạn có thể tìm mô tả bằng cách liên kết nhật ký workflow với các bảng định nghĩa tác vụ như T528T. Ví dụ Phê duyệt của quản lýPhê duyệt của giám đốcPhê duyệt của phó chủ tịch tài chính | |||
| Thời gian kết thúc EndTime | Ngày và giờ chính xác khi một hoạt động cụ thể hoàn tất. | ||
| Mô tả EndTime là dấu thời gian ghi nhận lúc một hoạt động kết thúc. Nhiều sự kiện do hệ thống tạo ra diễn ra tức thời, nghĩa là StartTime bằng EndTime. Trong khi đó, tác vụ do con người thực hiện như phê duyệt có thể có thời điểm bắt đầu và kết thúc riêng. Dấu thời gian này ghi nhận lúc công việc hoàn tất. Có EndTime riêng giúp đo chính xác hơn thời gian xử lý thực tế so với thời gian chờ. Kết hợp EndTime với StartTime, bạn có thể tính chỉ số ProcessingTime. Mức độ chi tiết này giúp phân tích việc sử dụng tài nguyên và hiệu quả của các tác vụ thủ công. Vì sao điều này quan trọng Ghi nhận lúc hoạt động hoàn tất, giúp tính thời gian xử lý thực tế và xem chi tiết hơn thời lượng của tác vụ. Lấy dữ liệu ở đâu Thông tin này được lấy từ nhật ký workflow, nơi có thể ghi nhận cả thời điểm tạo mục công việc (StartTime) và thời điểm hoàn tất (EndTime). Ví dụ 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Tiền tệ Currency | Mã tiền tệ của giá trị yêu cầu mua hàng. | ||
| Mô tả Thuộc tính này cho biết loại tiền tệ dùng để tính giá trị yêu cầu mua hàng, chẳng hạn USD, EUR hoặc JPY. Thông tin này giúp hiểu đúng giá trị yêu cầu, đặc biệt trong các tổ chức đa quốc gia sử dụng nhiều loại tiền tệ. Để phân tích và báo cáo tài chính chính xác, cần tính đến tiền tệ. Khi cộng gộp hoặc so sánh giá trị yêu cầu, bạn cần quy đổi tất cả số tiền về cùng một loại tiền tệ để kết quả có ý nghĩa. Thuộc tính này là điều kiện cần để thực hiện việc quy đổi. Vì sao điều này quan trọng Cung cấp thông tin cần thiết để hiểu giá trị yêu cầu mua hàng, hỗ trợ phân tích và so sánh tài chính chính xác trong môi trường sử dụng nhiều loại tiền tệ. Lấy dữ liệu ở đâu Thông tin này nằm trong bảng EBAN, trường WAERS. Ví dụ USDEURGBP | |||
Hoạt động Purchase to Pay - Requisition
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Đóng yêu cầu mua hàng | Cho biết dòng yêu cầu đã được xử lý đầy đủ và không thể tạo thêm đơn đặt hàng từ dòng này. Trạng thái này thường được tự động thiết lập khi toàn bộ số lượng đã được đặt mua. | ||
| Vì sao điều này quan trọng Hoạt động này đánh dấu việc hoàn tất thành công vòng đời của dòng yêu cầu. Điều đó xác nhận nhu cầu kinh doanh đã được chuyển thành đơn mua hàng. Lấy dữ liệu ở đâu Suy ra từ bảng EBAN. Sự kiện xảy ra khi chỉ báo 'Đã đóng' (EBAKZ) được thiết lập, thường là khi tổng số lượng trên các đơn đặt hàng bằng số lượng yêu cầu. Thu thập Dùng chứng từ thay đổi để tìm sự kiện chỉ báo 'Đã đóng' (EBAKZ) được thiết lập trong bảng EBAN. Loại sự kiện inferred | |||
| Hoàn tất bước phê duyệt | Xảy ra khi người phê duyệt chấp thuận yêu cầu mua hàng, hoàn tất một bước trong quy trình phê duyệt nhiều cấp. Sự kiện này được suy ra từ thay đổi trạng thái phê duyệt của yêu cầu. | ||
| Vì sao điều này quan trọng Hoạt động này cho phép phân tích chi tiết quy trình phê duyệt và đo thời gian xử lý ở từng bước. Qua đó, bạn có thể nhận biết người phê duyệt xử lý nhanh và các điểm nghẽn trong quy trình. Lấy dữ liệu ở đâu Suy ra từ chứng từ thay đổi (CDHDR/CDPOS) của bảng EBAN. Khi trạng thái mã phê duyệt (ví dụ: trường FRGZU) chuyển từ chưa phê duyệt sang đã phê duyệt đối với một mã cụ thể, sự kiện này được ghi nhận. Thu thập Theo dõi các thay đổi trong trường trạng thái phê duyệt của EBAN cho từng mã phê duyệt được xác định trong chiến lược. Loại sự kiện inferred | |||
| Phê duyệt yêu cầu mua hàng | Đánh dấu yêu cầu mua hàng đã được phê duyệt đầy đủ và có thể chuyển thành đơn đặt hàng. Mốc này được suy ra khi trạng thái phê duyệt tổng thể đạt trạng thái cuối cùng là đã phê duyệt. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng xác nhận quy trình thành công và thường được dùng làm điểm kết thúc khi phân tích thời gian xử lý. Mốc này cho biết yêu cầu đã qua mọi bước kiểm tra và bộ phận mua hàng có thể tiếp tục xử lý. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái trong bảng EBAN, cụ thể khi chỉ báo phê duyệt tổng thể (FRGZU) hoặc trạng thái xử lý (PROCSTAT) được cập nhật thành giá trị cuối cùng là 'Đã phê duyệt'. Thu thập Xác định thời điểm áp dụng mã phê duyệt cuối cùng hoặc trạng thái tổng thể của yêu cầu chuyển thành 'Đã phê duyệt'. Loại sự kiện inferred | |||
| Tạo đơn đặt hàng | Cho biết đơn đặt hàng đã được tạo và tham chiếu đến dòng yêu cầu mua hàng. Đây là sự kiện được hệ thống ghi nhận rõ ràng, liên kết yêu cầu với chứng từ mua hàng tiếp theo. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng và là kết quả thành công của quy trình yêu cầu mua hàng. Thời gian từ khi yêu cầu được phê duyệt đến khi tạo đơn đặt hàng là KPI quan trọng để đo hiệu quả mua hàng. Lấy dữ liệu ở đâu Được ghi nhận rõ ràng khi một dòng đơn đặt hàng được tạo. Liên kết này được lưu trong bảng EKPO (dòng đơn đặt hàng), gồm số yêu cầu nguồn (BANFN) và số dòng (BNFPO). Thu thập Nối bảng EKPO với EBAN theo số yêu cầu và số dòng. Ngày tạo dòng đơn đặt hàng đánh dấu thời điểm xảy ra sự kiện. Loại sự kiện explicit | |||
| Tạo yêu cầu mua hàng | Đánh dấu thời điểm yêu cầu mua hàng được tạo lần đầu trong hệ thống. Sự kiện này được ghi nhận rõ ràng khi người dùng lưu yêu cầu mới lần đầu, kèm theo thời gian tạo. | ||
| Vì sao điều này quan trọng Đây là điểm bắt đầu chính để phân tích vòng đời yêu cầu mua hàng. Mốc này cần thiết để đo thời gian xử lý từ đầu đến cuối, từ khi xác định nhu cầu đến khi yêu cầu được phê duyệt hoặc chuyển thành đơn đặt hàng. Lấy dữ liệu ở đâu Sự kiện này được ghi nhận rõ ràng từ bảng EBAN, dựa trên các trường ngày tạo (ERDAT) và giờ tạo (ERZEIT) của số yêu cầu mua hàng tương ứng (BANFN). Thu thập Dùng các trường thời gian tạo (ERDAT, ERZEIT) trong bảng EBAN cho từng yêu cầu mua hàng (BANFN). Loại sự kiện explicit | |||
| Từ chối yêu cầu mua hàng | Đánh dấu yêu cầu mua hàng bị người phê duyệt từ chối, khiến quy trình dừng lại. Sự kiện này được ghi nhận qua một cập nhật trạng thái cụ thể cho biết yêu cầu bị từ chối. | ||
| Vì sao điều này quan trọng Đây là điểm kết thúc khi quy trình không thành công. Phân tích tần suất, lý do và thời điểm từ chối giúp phát hiện vấn đề về tuân thủ chính sách, ngân sách hoặc chất lượng yêu cầu. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái trong bảng EBAN. Trạng thái xử lý (PROCSTAT) hoặc chỉ báo phê duyệt được đặt thành giá trị thể hiện rõ yêu cầu bị 'Từ chối'. Thu thập Dùng chứng từ thay đổi để xác định thời điểm trạng thái tổng thể trong EBAN được cập nhật thành 'Bị từ chối'. Loại sự kiện inferred | |||
| Bắt đầu bước phê duyệt | Cho biết yêu cầu mua hàng đang chờ một người phê duyệt hoặc nhóm phê duyệt cụ thể xử lý. Sự kiện này được suy ra khi trạng thái yêu cầu cho biết đang chờ một mã phê duyệt cụ thể. | ||
| Vì sao điều này quan trọng Hoạt động này giúp xác định điểm nghẽn trong chuỗi phê duyệt. Phân tích thời gian yêu cầu ở trạng thái này giúp phát hiện yêu cầu bị đình trệ và người phê duyệt đang quá tải. Lấy dữ liệu ở đâu Suy ra từ các trường trạng thái phê duyệt trong bảng EBAN (ví dụ: FRGZU) và cấu hình chiến lược phê duyệt tương ứng. Sự kiện bắt đầu khi một mã phê duyệt cụ thể trở thành bước tiếp theo cần xử lý. Thu thập Xác định thời điểm yêu cầu chuyển sang trạng thái đang chờ phê duyệt theo một mã phê duyệt cụ thể, dựa trên nhật ký workflow hoặc các trường trạng thái. Loại sự kiện inferred | |||
| Chỉnh sửa yêu cầu mua hàng | Xảy ra khi người dùng sửa một trường quan trọng trong yêu cầu sau khi tạo, chẳng hạn như số lượng, giá hoặc vật tư. Thao tác này được ghi lại rõ ràng trong hệ thống chứng từ thay đổi của SAP. | ||
| Vì sao điều này quan trọng Theo dõi các lần chỉnh sửa giúp phát hiện vòng lặp làm lại và ảnh hưởng của chúng đến thời gian xử lý. Nếu yêu cầu thường xuyên bị chỉnh sửa, có thể dữ liệu chưa chính xác hoặc nhu cầu đang thay đổi. Đây là những điểm cần ưu tiên cải tiến quy trình. Lấy dữ liệu ở đâu Được ghi lại rõ ràng trong các bảng chứng từ thay đổi của SAP (CDHDR và CDPOS) đối với các thay đổi trong bảng EBAN. Mỗi lần sửa một trường được theo dõi sẽ tạo một mục ghi nhận. Thu thập Trích xuất các sự kiện thay đổi từ CDHDR/CDPOS có lớp đối tượng là BANF cho yêu cầu mua hàng. Loại sự kiện explicit | |||
| Đặt lại phê duyệt | Đánh dấu sự kiện toàn bộ quy trình phê duyệt bị đặt lại, thường do yêu cầu mua hàng có thay đổi lớn. Khi đó, quy trình phê duyệt phải bắt đầu lại từ cấp đầu tiên. | ||
| Vì sao điều này quan trọng Hoạt động này cho thấy việc làm lại đáng kể, gây ảnh hưởng lớn đến thời gian xử lý. Xác định nguyên nhân đặt lại phê duyệt là bước quan trọng để tinh gọn quy trình và giảm chậm trễ. Lấy dữ liệu ở đâu Suy ra từ chứng từ thay đổi (CDHDR/CDPOS) của bảng EBAN. Sự kiện này được phát hiện khi các trường trạng thái phê duyệt (như FRGKZ hoặc FRGZU) bị xóa sau khi đã được thiết lập một phần hoặc đầy đủ. Thu thập Tìm trong nhật ký thay đổi trường hợp trạng thái phê duyệt chuyển từ đã phê duyệt về chưa phê duyệt. Loại sự kiện inferred | |||
| Gán nguồn cung | Đánh dấu người mua chỉ định nhà cung cấp, hợp đồng hoặc hồ sơ thông tin cụ thể cho một dòng yêu cầu đã được phê duyệt. Đây là bước quan trọng để chuẩn bị tạo đơn đặt hàng. | ||
| Vì sao điều này quan trọng Hoạt động này nối bước phê duyệt với bước đặt hàng. Đo thời gian gán nguồn cung giúp phát hiện chậm trễ trong khối lượng công việc của người mua và đánh giá hiệu quả tìm nguồn cung. Lấy dữ liệu ở đâu Suy ra khi một giá trị được nhập vào các trường liên quan đến nguồn cung trong bảng EBAN, chẳng hạn như nhà cung cấp cố định (LIFNR), hồ sơ thông tin (INFNR) hoặc hợp đồng (KONNR). Thu thập Dùng chứng từ thay đổi để theo dõi việc điền các trường như LIFNR, INFNR hoặc KONNR trong bảng EBAN. Loại sự kiện inferred | |||
| Gửi yêu cầu mua hàng để phê duyệt | Đánh dấu thời điểm người yêu cầu chính thức gửi yêu cầu, qua đó kích hoạt quy trình phê duyệt. Thời điểm này thường được suy ra khi hệ thống xác định chiến lược phê duyệt và trạng thái chuyển thành 'Đang chờ phê duyệt'. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng để bắt đầu tính KPI thời gian phê duyệt. Phân tích khoảng thời gian từ lúc tạo đến lúc gửi yêu cầu có thể giúp phát hiện chậm trễ trong khâu chuẩn bị. Lấy dữ liệu ở đâu Suy ra từ chứng từ thay đổi (CDHDR/CDPOS) của bảng EBAN, cụ thể khi các trường chiến lược phê duyệt (ví dụ: FRGST) được điền hoặc trạng thái tổng thể (PROCSTAT) chuyển sang trạng thái chờ phê duyệt. Thu thập Tìm mục đầu tiên trong chứng từ thay đổi cho biết quy trình phê duyệt bắt đầu hoặc trạng thái chuyển thành 'Đang chờ phê duyệt'. Loại sự kiện inferred | |||
| Rút yêu cầu mua hàng | Xảy ra khi người yêu cầu ban đầu hủy hoặc xóa yêu cầu trước khi quy trình xử lý hoàn tất. Thao tác này thường được ghi nhận rõ ràng bằng cách đặt cờ xóa cho một dòng yêu cầu. | ||
| Vì sao điều này quan trọng Theo dõi các yêu cầu bị rút giúp hiểu rõ biến động nhu cầu và lý do hủy. Đây là trạng thái kết thúc của yêu cầu, không cho phép xử lý tiếp. Lấy dữ liệu ở đâu Được ghi nhận rõ ràng khi trường chỉ báo xóa (LOEKZ) trong bảng EBAN được đặt cho một dòng yêu cầu. Thay đổi này được ghi lại trong CDHDR/CDPOS. Thu thập Tìm sự kiện trường chỉ báo xóa (LOEKZ) trong bảng EBAN được đặt thành 'L'. Loại sự kiện explicit | |||
Hướng dẫn trích xuất
Các bước
- Điều kiện cần: Đảm bảo bạn có tài khoản với quyền phù hợp trong SAP S/4HANA để truy cập các chế độ xem CDS cần thiết. Thông thường, tài khoản cần quyền với các đối tượng như S_TABU_NAM và quyền dùng công cụ xem dữ liệu.
- Xác định cách truy cập hệ thống: Chọn cách kết nối với cơ sở dữ liệu SAP S/4HANA để chạy truy vấn SQL. Các công cụ thường dùng gồm SAP HANA Studio, Eclipse IDE với ADT (ABAP Development Tools) hoặc ứng dụng SQL của bên thứ ba như DBeaver có thể kết nối qua SAP HANA database client.
- Xem lại truy vấn SQL: Tìm hiểu tập lệnh SQL được cung cấp. Tập lệnh dùng biểu thức bảng chung (CTE) để lấy dữ liệu cho các hoạt động khác nhau, rồi kết hợp chúng thành một nhật ký sự kiện thống nhất.
- Thay các giá trị giữ chỗ: Tìm và thay các giá trị giữ chỗ trong truy vấn. Bạn cần đặt khoảng ngày trích xuất theo định dạng
[YYYY-MM-DD]và chỉ định mã công ty phù hợp ([Your Company Code]) cho tổ chức của mình. - Chạy truy vấn: Chạy toàn bộ truy vấn SQL đã tùy chỉnh trên cơ sở dữ liệu SAP S/4HANA. Tùy vào lượng dữ liệu và khoảng ngày đã chọn, truy vấn có thể mất một lúc để chạy xong.
- Kiểm tra dữ liệu ban đầu: Khi truy vấn chạy xong, xem vài hàng đầu tiên trong kết quả. Kiểm tra các cột như PurchaseRequisitionId, ActivityName và EventTime có dữ liệu như mong đợi không, đồng thời xác nhận định dạng dữ liệu chính xác.
- Xử lý chuyển đổi dữ liệu: Truy vấn được thiết kế để xuất dữ liệu theo định dạng sẵn sàng cho process mining. Các hàm
CASTvàCONCATgiúp đảm bảo kiểu dữ liệu nhất quán. Thông thường, bạn không cần chuyển đổi thêm sau khi chạy truy vấn. - Xuất nhật ký sự kiện: Xuất toàn bộ kết quả từ công cụ SQL sang tệp CSV. Đặt mã hóa UTF-8 để tránh lỗi ký tự.
- Chuẩn bị tải lên: Trước khi tải lên công cụ process mining, kiểm tra tệp CSV có đúng tiêu đề cột (
PurchaseRequisitionId,ActivityName,EventTime, v.v.) và định dạng ngày giờ củaEventTimenhất quán, được nền tảng đích hỗ trợ. - Tải lên ProcessMind: Tải tệp CSV hoàn chỉnh vào dự án ProcessMind. Cấu hình dự án bằng cách ánh xạ
PurchaseRequisitionIdthành ID trường hợp,ActivityNamethành Hoạt động vàEventTimethành dấu thời gian.
Cấu hình
- CDS View chính: Quá trình trích xuất chủ yếu dùng
I_PurchaseRequisitionAPI01để lấy dữ liệu yêu cầu mua hàng,I_ChangeDocumentvàI_ChangeDocumentItemđể theo dõi thay đổi và cập nhật trạng thái, cùngI_PurchaseOrderItemAPI01để liên kết với đơn mua hàng. - Quyền truy cập: Người chạy truy vấn cần quyền đọc các CDS view nêu trên. Hãy hỏi nhóm bảo mật SAP về vai trò và quyền cần thiết.
- Lọc theo khoảng ngày: Cần lọc theo ngày tạo yêu cầu mua hàng (
CreationDate) để giới hạn lượng dữ liệu. Với lần phân tích đầu tiên, nên dùng dữ liệu trong khoảng 3 đến 6 tháng. - Lọc theo tổ chức: Lọc dữ liệu theo
CompanyCodeđể đảm bảo bạn phân tích đúng pháp nhân. Bạn cũng có thể lọc theoPurchaseRequisitionTypeđể tập trung vào một số quy trình mua sắm, chẳng hạn hàng hóa tiêu chuẩn hoặc dịch vụ. - Cấu hình Change Document: Việc ghi nhận các hoạt động như 'Đã sửa đổi yêu cầu mua hàng' và các bước phê duyệt phụ thuộc vào việc bật ghi nhật ký thay đổi cho các trường liên quan trong hệ thống SAP. Nếu thiếu sự kiện, hãy kiểm tra cấu hình hệ thống cho bảng EBAN.
- Hiệu năng: Với hệ thống rất lớn có hàng triệu yêu cầu mua hàng, chạy truy vấn trong thời gian dài có thể ảnh hưởng đến hiệu năng. Hãy cân nhắc chạy vào giờ thấp điểm hoặc trong môi trường phi sản xuất có dữ liệu mới được làm mới.
Truy vấn mẫu sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Các bước
- Xác nhận bạn có quyền đọc trực tiếp schema SAP HANA chứa EBAN và EBKN. Đồng thời, xác định các đối tượng change document và chứng từ mua hàng mà hệ thống dùng để ghi nhận thay đổi yêu cầu, xử lý phê duyệt, gán nguồn cung ứng, tham chiếu đơn mua hàng và đóng yêu cầu. Các đối tượng và trường có thể khác nhau tùy phiên bản và cấu hình, vì vậy hãy thay từng giá trị giữ chỗ trong ngoặc vuông bằng đối tượng hoặc trường tương ứng trong hệ thống của bạn.
- Trong SAP GUI, dùng giao dịch SE16H hoặc công cụ quản trị cơ sở dữ liệu được phê duyệt để kiểm tra EBAN và EBKN, xác minh các trường khóa của yêu cầu mua hàng và xác nhận các trường ngày, giờ, người dùng, trạng thái, xóa, phê duyệt, phân bổ tài khoản và tham chiếu chứng từ mua hàng hiện có. Dùng SE11 hoặc từ điển dữ liệu SAP để kiểm tra định nghĩa trường. Không để lộ dữ liệu sản xuất trong quá trình thử nghiệm.
- Xác định nguồn change document đã cấu hình cho các lần sửa đổi yêu cầu mua hàng và thay đổi phê duyệt. Truy vấn cần một nguồn thay đổi đã chuẩn hóa tên là [Your requisition change document source], gồm các trường số yêu cầu, số dòng, trường đã thay đổi, giá trị cũ, giá trị mới, ngày thay đổi, giờ thay đổi và người dùng. Trước khi chạy, ánh xạ nguồn này với các bảng change document hoặc CDS view phù hợp trong hệ thống.
- Xác định nguồn workflow hoặc phê duyệt đã cấu hình cho các sự kiện gửi yêu cầu, đặt lại phê duyệt, bắt đầu bước phê duyệt, hoàn tất bước phê duyệt, phê duyệt cuối cùng và từ chối. Truy vấn cần [Your requisition approval event source], với mỗi dòng tương ứng một lần chuyển trạng thái hoặc phê duyệt, gồm các trường số yêu cầu, số dòng, loại sự kiện, mã phê duyệt hoặc nhóm phê duyệt, người phê duyệt, ngày sự kiện, giờ sự kiện và trạng thái. Ánh xạ nguồn này với dữ liệu lưu trữ phê duyệt hoặc workflow mà cấu hình S/4HANA của bạn sử dụng.
- Xác định nguồn gán nguồn cung ứng, tham chiếu đơn mua hàng và đóng yêu cầu. Truy vấn cần các nguồn [Your requisition source assignment source], [Your requisition purchase order reference source] và [Your requisition closure source]. Ánh xạ các giá trị giữ chỗ này với bảng hoặc view được phê duyệt trong hệ thống. Chỉ ghi nhận việc tạo đơn mua hàng khi có tham chiếu rõ ràng từ dòng đơn mua hàng đến dòng yêu cầu mua hàng, không suy ra từ hoạt động mua sắm không liên quan.
- Đặt khoảng trích xuất bằng [Start date] và [End date]. Nên dùng khoảng từ ba đến sáu tháng cho lần chạy đầu tiên. Chỉ mở rộng khoảng thời gian sau khi đã kiểm tra hiệu năng cơ sở dữ liệu và lượng sự kiện. Truy vấn lọc theo ngày tạo và ngày sự kiện, đồng thời giữ mã yêu cầu mua hàng làm mã định danh case.
- Chạy truy vấn trong ứng dụng SQL được phê duyệt và kết nối với SAP HANA. Chỉ thay thông tin kết nối bên ngoài truy vấn, tham số ngày, bộ lọc riêng của công ty và các giá trị giữ chỗ về nguồn hoặc trường đã được ghi rõ. Giữ nguyên chính xác tên các cột đầu ra: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount và RequisitionStatus.
- Kiểm tra sự kiện trùng lặp, độ chính xác của dấu thời gian, múi giờ và mức chi tiết theo dòng hay theo chứng từ. Truy vấn xuất mã định danh case ở cấp chứng từ và giữ thông tin dòng ở bên trong. Nếu nhiều dòng tạo ra cùng hoạt động và dấu thời gian, hãy giữ riêng từng dòng, trừ khi thiết kế ProcessMind của bạn yêu cầu loại trùng.
- Xác nhận mọi hoạt động bắt buộc đều xuất hiện dưới dạng giá trị ActivityName, EventTime có dữ liệu và hợp lý theo trình tự thời gian, đồng thời mã định danh case bắt buộc không bị null. Đối chiếu số lượng với báo cáo SAP hoặc dữ liệu vận hành đã được phê duyệt trong cùng khoảng ngày.
- Xuất kết quả thành CSV UTF-8 hoặc định dạng bảng khác được ProcessMind hỗ trợ. Thêm dòng tiêu đề, giữ dấu thời gian tương thích ISO, để giá trị null thành ô trống, rồi tải tệp lên với PurchaseRequisitionId làm mã định danh case, ActivityName làm cột hoạt động và EventTime làm cột dấu thời gian.
Cấu hình
- Mã định danh case: Dùng số chứng từ yêu cầu mua hàng trong EBAN, đặt tên là PurchaseRequisitionId. Nếu quy trình được cấu hình ở cấp dòng, hãy dùng khóa ghép đã được ghi rõ, chẳng hạn số yêu cầu và số dòng, rồi áp dụng cùng khóa đó cho mọi sự kiện.
- Nguồn chính: EBAN cung cấp dữ liệu dòng yêu cầu mua hàng. EBKN cung cấp thông tin phân bổ tài khoản và dữ liệu bổ sung về phòng ban hoặc trung tâm chi phí. Trước khi chạy, hãy xác nhận chính xác tên trường và kiểu dữ liệu trong từ điển dữ liệu SAP.
- Nguồn sự kiện: Truy vấn cố ý dùng các giá trị giữ chỗ chuyên dụng cho nguồn thay đổi, phê duyệt, gán nguồn cung ứng, tham chiếu đơn mua hàng và đóng yêu cầu. Các nguồn này phụ thuộc vào phiên bản S/4HANA, thiết kế workflow, quy trình phê duyệt, chức năng nghiệp vụ được kích hoạt và phần mở rộng riêng của khách hàng.
- Khoảng ngày: Bắt đầu với khoảng từ ba đến sáu tháng. Khi có thể, hãy giới hạn khoảng ngày trên các trường ngày được lập chỉ mục hoặc hỗ trợ loại bỏ phân vùng. Với lần tải tăng dần, hãy để các khoảng trích xuất chồng lấn đủ để ghi nhận thay đổi đến muộn, sau đó loại trùng theo case, hoạt động, dấu thời gian, dòng và khóa sự kiện nguồn.
- Bộ lọc nghiệp vụ: Chỉ cấu hình [Company code filter], [Document type filter], [Purchasing group filter] và [Plant filter] khi các trường này có sẵn và ý nghĩa nghiệp vụ đã được xác nhận. Tránh lọc theo trạng thái nếu mục tiêu là ghi nhận toàn bộ vòng đời.
- Ánh xạ trạng thái: Cấu hình các giá trị cho Đang chờ phê duyệt, đã phê duyệt cuối cùng, bị từ chối, đặt lại, mã phê duyệt đang chờ và đã đóng theo chiến lược phê duyệt hoặc cấu hình workflow của hệ thống đích. Không giả định một mã trạng thái dùng chung cho mọi hệ thống SAP.
- Ánh xạ sửa đổi: Ghi nhận các thay đổi về số lượng, giá, vật tư, ngày giao hàng, phân bổ tài khoản và các trường khác mà quy trình của bạn xác định là quan trọng. Truy vấn có điều kiện rõ ràng cho các trường quan trọng đã liệt kê và yêu cầu nguồn cung cấp tên trường đã thay đổi.
- Xử lý dấu thời gian: Kết hợp ngày và giờ sự kiện theo múi giờ cơ sở dữ liệu, sau đó ghi rõ mọi chuyển đổi sang UTC. Nếu nguồn chỉ lưu ngày, chỉ dùng nửa đêm khi không có dấu thời gian chính xác hơn và ghi lại hạn chế này.
- Hiệu năng: Giới hạn lần trích xuất đầu tiên theo ngày và phạm vi nghiệp vụ, chỉ chọn các cột cần thiết, tránh join không giới hạn với lịch sử thay đổi hoặc workflow lớn, đồng thời xem kế hoạch thực thi HANA. Nếu cần trích xuất nhiều lần, hãy chuẩn hóa và lưu tạm các nguồn sự kiện.
- Quyền truy cập và điều kiện tiên quyết: Xin quyền đọc EBAN, EBKN, các nguồn thay đổi và workflow đã cấu hình, dữ liệu gán nguồn cung ứng, dữ liệu tham chiếu đơn mua hàng và dữ liệu đóng yêu cầu. Xác nhận quyền truy cập trực tiếp cơ sở dữ liệu đã được phê duyệt, các chức năng mua sắm và workflow liên quan đang hoạt động, đồng thời có giấy phép cơ sở dữ liệu SAP HANA hoặc công cụ quản trị cần thiết.
- Bảo mật: Áp dụng quyền truy cập tối thiểu cần thiết, bảo vệ mã định danh người dùng và người phê duyệt, đồng thời tuân thủ quy định của tổ chức về trích xuất thông tin mua sắm và tài chính.
Truy vấn mẫu sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Bạn đã sẵn sàng bắt đầu chưa?
Dùng mẫu này để chuẩn bị dữ liệu một cách tự tin và khai thác process mining cho quy trình Purchase to Pay - Requisition. Bắt đầu tối ưu hiệu quả ngay hôm nay!
Chấm dứt chậm trễ trong yêu cầu mua hàng P2P: tối ưu quy trình làm việc ngay!
Tinh gọn quy trình, rút ngắn thời gian xử lý và giảm 30% thời gian chu kỳ.
Không cần thẻ tín dụng, thiết lập trong 5 phút.