`confirm_user_request`

Người yêu cầu chấp nhận báo giá của admin và chia từng khoản phí: corporate_amount do công ty trả, phần còn lại của giá do người yêu cầu trả. API này đưa yêu cầu ra khỏi ISSUED trong luồng trạng thái — sang AWAITING_PERSONAL_PAYMENT khi người yêu cầu tự trả một phần, hoặc sang CONFIRMED khi công ty trả toàn bộ.

Đây là một GraphQL mutation trả về UserRequest. Chỉ người tạo yêu cầu mới gọi được, và chỉ khi yêu cầu đang ở trạng thái ISSUED.

Input

input: ConfirmUserRequestInput!

Trường	Kiểu	Bắt buộc	Mô tả
`id`	`String`	Có	User request cần xác nhận.
`fees` mới	`[ConfirmUserRequestFeeInput!]`	Không	Phần công ty trả của từng khoản phí. Khoản nào không gửi thì công ty trả toàn bộ.
`corporate_amount` đã bỏ	`Decimal`	—	Được thay bằng `corporate_amount` của từng khoản phí. Gửi trường này giờ sẽ làm lỗi request.

ConfirmUserRequestFeeInput:

Trường	Kiểu	Bắt buộc	Mô tả
`id`	`String`	Có	`id` của một khoản trong `fees` của yêu cầu.
`corporate_amount`	`Decimal`	Có	Phần công ty trả, từ 0 đến `price` của khoản đó, tính theo `currency` của yêu cầu. 0 nghĩa là người yêu cầu trả cả khoản.

Tổng của yêu cầu được tính từ các khoản phí:

corporate_amount là tổng corporate_amount của các khoản phí.
personal_amount là amount - corporate_amount: phần người yêu cầu trả bằng begin_personal_payment.
Yêu cầu báo giá trước khi có khoản phí thì không có khoản nào để gửi: công ty trả toàn bộ amount.

Mutation
mutation {
  confirm_user_request(input: {
    id: "3JMY..."
    fees: [
      { id: "3Jwm...seat", corporate_amount: 100000 }
      { id: "3Jwm...other", corporate_amount: 0 }
    ]
  }) {
    id code status amount currency corporate_amount personal_amount
    fees { id fee_type price corporate_amount }
  }
}

Sau khi xác nhận

Cách chia	Trạng thái sau khi xác nhận	Tiếp theo
Người yêu cầu tự trả một phần (`personal_amount` > 0)	`AWAITING_PERSONAL_PAYMENT`	Người yêu cầu thanh toán bằng `begin_personal_payment`; sau đó yêu cầu chuyển sang `CONFIRMED`
Công ty trả toàn bộ	`CONFIRMED`	Xem bên dưới

Từ CONFIRMED:

Phần công ty trả	Kết quả
Lớn hơn 0, và chính sách của công ty cần phê duyệt	Chuyển cho người phê duyệt của công ty, lần lượt từng cấp. `RESOLVED` khi mọi cấp đã duyệt, `REJECTED` nếu một cấp từ chối. Theo dõi bằng `booking_request_progress`.
Bằng 0, hoặc chính sách không cần phê duyệt	`RESOLVED` ngay

Fetch lại sau khi xác nhận

Response trả về trạng thái do bước xác nhận đặt, nên có thể là CONFIRMED dù yêu cầu đã chuyển sang RESOLVED. Hãy fetch lại yêu cầu trước khi hiển thị trạng thái.

Mã lỗi

Mã lỗi	Ý nghĩa
`user_request_fee_not_found`	Một `id` không thuộc các khoản phí của yêu cầu.
`duplicate_user_request_fee`	Cùng một `id` khoản phí được gửi hai lần.
`invalid_corporate_amount`	`corporate_amount` của một khoản phí bị âm.
`corporate_amount_exceeds_price`	`corporate_amount` của một khoản phí lớn hơn `price` của nó.
`<status>_user_request`	Yêu cầu không ở `ISSUED` — ví dụ `confirmed_user_request`.
`unauthorized`	Người gọi không phải người tạo yêu cầu.
`not_found`	`id` không tồn tại.

API này cũng có thể trả về Lỗi middleware. Mọi mã lỗi của user request được liệt kê chung trong Lỗi của User Request.

Input​

Sau khi xác nhận​

Mã lỗi​

Input

Sau khi xác nhận

Mã lỗi