Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Nghiệp vụ

IT

Người lập

Người duyệt

Người lập

Người duyệt

Tên, Chức danh





Ngày ký





Jira Link

[BPMKVH-1899] Thiết kế luồng happy A1.05 - Jira


1. Card (Mô tả tính năng)

Là người xử lý công việc tôi có quyền thực hiện từ chối/ yêu cầu điều chỉnh công việc nếu công việc được giao không đúng trách nhiệm của tôi hoặc đầu vào chưa đầy đủ để tôi sẵn sàng tiếp nhậnthiết kế quy trình, tôi muốn thể hiện được bước nộp thầu của nhà thầu (từ hệ thống portal) trên hệ thống BPM

2. Confirmation/ Acceptance Criteria (Tiêu chí nghiệm thu)

...

2.1. Tôi muốn BPM nhận được thông tin sẽ được đẩy từ Portal sang  khi nhà thầu thực hiện nhấn nút "Xác nhận Tham gia", "Xác nhận Từ chối", "Xác nhận Tham gia lại"

    • Mã nhà thầu
    • Trạng thái
    • Số lượng nhà thầu đã mời thầu

2.2. Tôi muốn trường hợp mỗi lần nhà thầu thực hiện "xác nhận Nộp thầu", hệ thống sẽ  thông tin sẽ được đẩy từ Portal sang BPM bao gồm:

      • Mã nhà thầu
      • Vòng nộp thầu
      • Loại hồ sơ dự thầu Đã nộp (Hồ sơ kỹ thuật, hồ sơ tài chính, hồ sơ năng lực, hợp đồng mẫu)
      • Hồ sơ dự thầu đã nộp
      • Thời gian nộp thầu

2.3. Tôi muốn hệ thống kiểm tra điều kiện khi tất cả nhà thầu đã thực hiện xác nhận tham gia/từ chối và tất cả nhà thầu thầu xác nhận tham gia đã hoàn thành nộp thầu (Trường hợp tất cả đã xác nhận mà chưa hết thời gian) để kích hoạt luồng Mở thầu

2.4. Khi hết thời gian nộp thầu, tôi muốn hệ thống BPM nhận từ hệ thống Portal và kiểm tra điều kiện đã có nhà thầu nộp thầu từ đó kích hoạt công việc Mở thầu, thông tin nhận về bao gồm:

    • Mã gói thầu
    • Vòng nộp thầu
    • Trạng thái

Quy trình Thiết kế luồng A1.05 


                             Image Added

3. Conversation (Mô tả chi tiết)

...

  • Lý do từ chối (bắt buộc)
  • Tệp đính kèm (không bắt buộc)

       Hệ thống ghi nhận thông tin, lý do từ chối vào ghi chú dự án. Với những công việc bị từ chối >1 lần hệ thống lùi khoảng cách ghi chú để thể hiện

Image Removed

    1. Thông báo:
    • Gửi thông báo (email + chuông) tới:
      • Người bị từ chối
      • Những người thực hiện công việc từ bước Bị từ chối → bước từ chối

...

  • Cho phép từ chối/YCĐC các bước thông thường hoặc, bước trình (không bao gồm các bước phê duyệt)
  • Cho phép từ chối/YCĐC các bước đã sinh ra trong quy trình (không cho phép từ chối/YCĐC các bước chưa sinh ra)
  • Cho phép lựa chọn công việc cần trả về (đối với node linh động)

...

  • Cấu hình cho phép người dùng tự lựa chọn việc thực thi/trình từ đầu hoặc thực thi/trình đến cấp yêu cầu điều chỉnh
  • Cấu hình cho phép người dùng chỉ có thể thực thi/trình tuần tự công việc theo quy trình
  • Cấu hình cho phép người dùng chỉ có thể thực thi/trình thẳng đến bước yêu cầu điều chỉnh

4. Use case (Các trường hợp có thể phát sinh)

4.1 Luồng tuần tự

Image Removed

     4.1.1 Các trường hợp trả lại

  • Trả về cách bước: Bước 5 trả về bước 3. Bước 3 trả về bước 1

     4.1.2 Các trường hợp đi tiếp

  • Bước 1 đi tiếp theo quy trình, Bước 3 đi tiếp theo quy trình
  • Bước 1 đi tiếp theo quy trình, Bước 3 nhảy bước
  • Bước 1 nhảy bước, bước 3 đi tiếp theo quy trình
  • Bước 1 nhảy bước, bước 3 nhảy bước

4.2 Luồng song song cố định

Image Removed

     Các trường hợp trả lại

  • Bước 4 trả về bước 3a. Bước 3a trả về bước 3b hoặc 3c 
    • Bước 3b thực hiện đi tiếp theo quy trình → chuyển đến Bước 4 (do bước 3a đã hoàn thành)
    • Bước 3b thực hiện trả về bước yêu cầu → sinh lại công việc Bước 3aBước 3a thực hiện đi tiếp → đến bước 4 (do bước 3b đã hoàn thành)
    • Bước 3b thực hiện trả về bước yêu cầu → sinh công việc Bước 3aBước 3a thực hiện trả về bước yêu cầu → đến Bước 4
  • Bước 4 trả về bước 3a. Bước 3a trả về Bước 2
    • Bước 2 thực hiện đi tiếp theo quy trình → sinh công việc bước 3a, 3b, 3cBước 3a thực hiện đi tiếp theo quy trình, Bước 3b, 3c xử lý bình thường → sinh công việc bước 4
    • Bước 2 thực hiện đi tiếp theo quy trình → sinh công việc bước 3a, 3b, 3cBước 3a thực hiện nhảy bước → sinh công việc bước 4, Bước 3b, 3c xử lý bình thường → sinh công việc bước 4 lần tiếp theo?
    • Bước 2 thực hiện nhảy bước → sinh công việc bước 3aBước 3a thực hiện đi tiếp → sinh công việc bước 4 (do 3b và 3c đã hoàn thành)
    • Bước 2 thực hiện nhảy bước → sinh công việc bước 3aBước 3a thực hiện nhảy bước → sinh công việc bước 4
  • Bước 3a trả về bước 2. Bước 2 trả về bước 1
    • Bước 1 thực hiện đi tiếp theo quy trình → sinh công việc bước 2Bước 2 thực hiện đi tiếp theo quy trình,  sinh công việc bước 3a, 3b, 3c
    • Bước 1 thực hiện đi tiếp theo quy trình → sinh công việc bước 2Bước 2 thực hiện nhảy bước,  sinh công việc bước 3a → hoàn thành công việc bước 3a → sinh công việc bước 4 (do bước 3b và 3c đã hoàn thành trước đó)
  • Bước 3a, 3b trả về bước 2. Bước 2 trả về bước 1
    • Bước 2 thực hiện đi tiếp công việc → sinh công việc bước 3a, 3b, 3c
    • Bước 2 thực hiện nhảy bước → sinh công việc bước 3a và 3b → hoàn thành bước 3a và 3b → sinh ra công việc bước 4 (do bước 3c đã hoàn thành trước đó)
  • Bước 5 trả về gateway để cả 3 bước 3a, 3b, 3c thực hiện lạ → có phát sinh nghiệp vụ này không?
    • Bước 3a, 3b, 3c thực hiện chạy tiếp quy trình → sinh công việc Bước 4
    • Bước 3a, 3b, 3c thực hiện nhảy bước → sinh ra công việc bước 5
    • Bước 3a thực hiện chạy tiếp quy trình, bước 3b 3c thực hiện nhảy bước → xử lý thế nào
  • Bước 5 trả về nhiều bước 3a, 3b, 3c, cả bước 3a và 3b trả về bước 3c
    • Bước 3c hoàn thành → bước 3a 3b từ chối → sinh công việc Bước 3c lần 3 → hoàn thành Bước 3c lần 3 → sinh công việc Bước 4
    • Bước 3a, 3b, 3c từ chối về các bước khác nhau?

4.3 Luồng node linh động

Image Removed

Các trường hợp trả lại

  • Bước 5 trả về node linh động 1 (1 công việc):
    • Công việc node linh động sinh ra → hoàn thành công việc linh động 1 sinh ra công việc lựa chọn thực hiện theo quy trình → sinh ra công việc bước 3
    • Công việc node linh đông sinh ra → hoàn thành công việc linh động 1 sinh ra công việc lựa chọn nhảy bước → sinh ra công việc bước 5
  • Bước 5 trả về node linh động 1 (nhiều công việc song song):
    • Công việc node linh động sinh ra → hoàn thành công việc linh động 1 sinh ra công việc lựa chọn thực hiện theo quy trình → sinh ra công việc bước 3 (do các công việc linh động khác trước đó đã hoàn thành)
    • Công việc node linh đông sinh ra → hoàn thành công việc linh động 1 sinh ra công việc lựa chọn nhảy bước → sinh ra công việc bước 5

...

  • Công việc node linh động sinh ra → hoàn thành công việc linh động 1 sinh ra công việc lựa chọn thực hiện theo quy trình → sinh ra công việc công việc linh động 2 
  • Công việc node linh đông sinh ra → hoàn thành công việc linh động 1 sinh ra công việc lựa chọn nhảy bước → sinh ra công việc bước 5

...

  • Công việc song song 1 sinh ra → hoàn thành lựa chọn thực hiện theo quy trình → sinh ra công việc công việc Tuần tự 3 (do công việc song song 2 đã hoàn thành trước đó) 
  • Công việc song song 1 sinh ra → hoàn thành lựa chọn nhảy bước → sinh ra công việc Bước 5 

...

  • Bước 1 sinh ra → lựa chọn thực hiện theo quy trình → sinh ra công việc Node linh động 1
  • Bước 1 sinh ra → lựa chọn thực hiện theo quy trình → sinh ra công việc Node linh động 2

...

4.4 Trả về 2 lần khác subprocess

Image Removed

...

3.1. UI/UX

3.2. Luồng


3.3 API Spec

Panel
titleAPI tổng hợp hồ sơ dự thầu

Method

GET

URL

application/tender-package/submission/check-completeness

Description

API tổng hợp hồ sơ dự thầu

Note

API mới tổng hợp hồ sơ dự thầu.

1. Headers

STT

Field

Source Data Type / Length 

Description

Sample Values

1authorization<token>Token của người dùng đăng nhậpBearer eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3NjY0NTU3ODksInVzZXIiOiJ7XCJpZFwiOjIwMjAsXCJ1c2VybmFtZVwiOlwiMDM3NDc4ODQwNVwiLFwibmFtZVwiOlwiQ2h1IFRo4buLIExpw6puXCIsXCJyb2xlc1wiOltdLFwibWFwQmVhdXR5U2Fsb25cIjp7XCJicG0ucmVib3JuLnZuXCI6Nn0sXCJlbXBsb3llZUlkXCI6NTMxLFwiYnJhbmNoSWRcIjoyM30ifQ.wrvIFd-Q2kHgkTmPf6ryMY6aDIgXpNsWmSvvifQWc5k

2. Request

STT

Field

Require

Data Type / Length

Description

Note

Sample Values

1packageIdtrueIntegerid gói thầu

2roundtrueIntegervòng nộp thầu

3. Response / Incoming Data Specification

STT

Field

Data Type / Length

Description

Note

Sample Values

1codeInteger0: thành công còn lại thất bại

2messageStringmessage

3resultObjectkết quả trả ra

4(result) statusInteger0: chưa đủ điều kiện,  1: đủ điều kiện mở thầu

5(result) docTypesList<Object>Danh sách loại hồ sơ nhà thầu nộp

6(docTypes) idIntegerid loại hồ sơ (hồ sơ tài chính...)

7(docTypes) nameStringtên loại hồ sơ

==> Logic xử lý: Khi tất cả nhà thầu đã thực hiện xác nhận tham gia/từ chối và tất cả nhà thầu thầu xác nhận tham gia đã hoàn thành nộp thầu → Kích hoạt dây đi tiếp luồng "Mở thầu"

3.4 Mô tả các trường dữ liệu trên từng màn hình của từng công việc

3.4.1. Bước nhà thầu nộp thầu

3.4.1.1 Receive Task "Nhà thầu nộp thầu"

  1. Tại bước này hệ thống sẽ ghi nhận thông tin được phản hồi từ hệ thống Portal:
  • Thông tin nhà thầu xác nhận tham gia/từ chối tham gia gói thầu: Thông tin sẽ được đẩy từ Portal sang BPM mỗi lần nhà thầu thực hiện nhấn nút "Xác nhận Tham gia", "Xác nhận Từ chối", "Xác nhận Tham gia lại"
    • Mã nhà thầu
    • Trạng thái: Tham gia, Từ chối
    • Số lượng nhà thầu đã mời thầu
  • Thông tin nộp thầu của nhà thầu: Thông tin sẽ được đẩy từ Portal sang BPM mỗi lần nhà thầu thực hiện "xác nhận Nộp thầu"
    • Mã nhà thầu
    • Vòng nộp thầu
    • Loại hồ sơ dự thầu Đã nộp (Hồ sơ kỹ thuật, hồ sơ tài chính, hồ sơ năng lực, hợp đồng mẫu)
    • Thời gian nộp thầu

    2. Receive task sẽ được hoàn thành trên điều kiện: Khi tất cả nhà thầu đã thực hiện xác nhận tham gia/từ chối và tất cả nhà thầu thầu xác nhận tham gia đã hoàn thành nộp thầu (Service task tổng hợp kết quả)

    3. Với trường hợp gói thầu bị phát hành lần 2 trở lên (trường hợp công việc bị từ chối về bước phát hành hoặc bước trước phát hành):

  • Trường hợp còn thời gian nộp thầu: Hệ thống Portal bỏ qua
  • Trường hợp hết thời gian nộp thầu: Portal trả về cho BPM thời gian kết thúc để hệ thống BPM kích hoạt điều kiện hết giờ và đi tiếp đến bước tiếp theo.

3.4.1.2 Conditional intermediate catch event (Hết giờ nộp thầu)

Node nhận tín hiệu gói thầu đã được đóng (do hết thời gian nộp thầu) hệ thống BPM nhận từ hệ thống Portal từ đó kích hoạt công việc Mở thầu

Hệ thống Portal gửi tín hiệu cho BPM tại thời điểm hết thời gian nộp thầu.

Thông tin đóng thầu bao gồm:

  • Mã gói thầu
  • Vòng nộp thầu
  • Trạng thái: Đã đóng thầu

3.4.1.3 Service task Tổng hợp hồ sơ dự thầu

Service task với mục đích tổng hợp dữ liệu từ Send task "Nhà thầu nộp thầu" để kiểm tra điều kiện đi tiếp công việc "Mở thầu":

Khi tất cả nhà thầu đã thực hiện xác nhận tham gia/từ chối và tất cả nhà thầu thầu xác nhận tham gia đã hoàn thành nộp thầu → Kích hoạt dây đi tiếp luồng "Mở thầu"

3.4.1.4 Script task Biến đổi dữ liệu hồ sơ dự thầu

Script task với mục đích biến đổi dữ liệu đã tổng hợp để cho ra kết quả có bao nhiêu loại hồ sơ đã được nộp từ đó là cơ sở để kích hoạt số lượng công việc, dây công việc đánh giá tương ứng khi thực hiện mở thầu.

Dữ liệu sẽ được biến đổi thành các biến:

STT

Biến dữ liệu

Kiểu dữ liệu

Mô tả

1

biddingtypeQuantity

Số nguyên

Số lượng loại hồ sơ nộp thầu.

Dùng để xác định số lượng luồng công việc đáng giá song song.

2

tchnclDocument

Văn bản

Thể hiện việc loại hồ sơ này có được nộp hay không:

  • True: có ít nhất 01 hồ sơ kỹ thuật được nộp
  • False: Không có hồ sơ nào được nộp

Dùng để xác định việc kích hoạt dây đánh giá hồ sơ kỹ thuật

3

fnclDocument

Văn bản

Thể hiện việc loại hồ sơ này có được nộp hay không:

  • True: có ít nhất 01 hồ sơ tài chính được nộp
  • False: Không có hồ sơ nào được nộp

Dùng để xác định việc kích hoạt dây đánh giá hồ sơ tài chính

4

cpctPrfDocument

Văn bản

Thể hiện việc loại hồ sơ này có được nộp hay không:

  • True: có ít nhất 01 hồ sơ năng lực được nộp
  • False: Không có hồ sơ nào được nộp

Dùng để xác định việc kích hoạt dây đánh giá hồ sơ kỹ thuật

5

ctrctTmplDocument

Văn bản

Thể hiện việc loại hồ sơ này có được nộp hay không:

  • True: có ít nhất 01 hồ sơ hợp đồng mẫu được nộp
  • False: Không có hồ sơ nào được nộp

Dùng để xác định việc kích hoạt dây đánh giá hồ sơ kỹ thuật