21 thg 7, 2025·8 phút
Cách xây dựng ứng dụng web cho quy trình phê duyệt mua sắm
Hướng dẫn từng bước để lên kế hoạch, thiết kế và xây dựng ứng dụng web mua sắm với yêu cầu mua, định tuyến phê duyệt, bản ghi kiểm toán, tích hợp và bảo mật.
Hướng dẫn từng bước để lên kế hoạch, thiết kế và xây dựng ứng dụng web mua sắm với yêu cầu mua, định tuyến phê duyệt, bản ghi kiểm toán, tích hợp và bảo mật.
Trước khi viết spec hay chọn công cụ, hãy làm rõ tại sao bạn xây ứng dụng web mua sắm. Nếu bỏ qua bước này, bạn có thể tạo ra một hệ thống yêu cầu mua hàng tuy hoạt động về mặt kỹ thuật nhưng không giảm được ma sát thực sự—phê duyệt chậm, trách nhiệm không rõ ràng, hoặc “mua sắm bóng tối” diễn ra qua email và chat.
Bắt đầu bằng cách nêu rõ vấn đề bằng ngôn ngữ dễ hiểu và gắn với kết quả có thể đo được:
Một câu hỏi hữu ích: Chúng ta sẽ dừng làm gì nếu ứng dụng hoạt động hoàn hảo? Ví dụ: “dừng phê duyệt qua chuỗi email” hoặc “dừng nhập cùng dữ liệu vào ERP nhiều lần”.
Một quy trình phê duyệt mua sắm chạm đến nhiều người hơn bạn nghĩ. Xác định các bên sớm và ghi lại những yêu cầu không thể bỏ qua:
Mời ít nhất một người từ mỗi nhóm vào một buổi làm việc ngắn để thống nhất cách định tuyến phê duyệt nên hoạt động.
Ghi ra “tốt hơn” nghĩa là gì bằng các chỉ số bạn có thể đo sau khi ra mắt:
Chúng sẽ là sao Bắc Đẩu khi bạn tranh luận về tính năng sau này.
Các lựa chọn phạm vi sẽ quyết định mô hình dữ liệu, quy tắc nghiệp vụ và tích hợp. Xác nhận:
Giữ pha 1 chặt chẽ, nhưng ghi lại những gì bạn cố tình chưa làm. Điều đó giúp mở rộng sau này dễ dàng hơn mà không chặn bản phát hành đầu tiên.
Trước khi thiết kế màn hình hay cơ sở dữ liệu, hãy có bức tranh rõ ràng về mọi việc diễn ra từ “Tôi cần mua cái này” tới “đã được phê duyệt và đặt hàng.” Điều này ngăn bạn tự động hóa một quy trình chỉ hoạt động trên giấy—hoặc chỉ tồn tại trong đầu một người.
Liệt kê mọi điểm nhập mà người dùng dùng: email gửi procurement, mẫu bảng tính, tin nhắn chat, biểu mẫu giấy, hoặc yêu cầu tạo trực tiếp trong ERP.
Với mỗi điểm nhập, ghi những thông tin thường được cung cấp (hàng hóa, nhà cung cấp, giá, cost center, lý do kinh doanh, tệp đính kèm) và những gì thường thiếu. Trường thiếu là lý do lớn khiến yêu cầu bị trả về và tắc.
Map “happy path” trước: requester → quản lý → chủ ngân sách → procurement → tài chính (nếu cần). Sau đó ghi các biến thể:
Một sơ đồ đơn giản là đủ. Quan trọng là nắm được điểm nào quyết định rẽ nhánh.
Ghi các trường hợp mọi người xử lý thủ công:
Đừng vội phán xét ngoại lệ—chỉ ghi lại để quy tắc workflow có thể xử lý chúng một cách có chủ ý.
Thu thập ví dụ cụ thể về chậm trễ: approver không rõ, thiếu xác nhận ngân sách, nhập dữ liệu trùng lặp, và không có bản ghi kiểm toán đáng tin cậy. Ghi rõ ai sở hữu từng chuyển giao (requester, manager, procurement, finance). Nếu “mọi người” chịu trách nhiệm một bước, thì thực tế là không ai cả—và ứng dụng của bạn nên làm rõ điều đó.
Sơ đồ workflow hữu ích, nhưng đội vẫn cần thứ có thể xây dựng: một tập yêu cầu rõ ràng mô tả app phải làm gì, dữ liệu cần thu thập, và “xong” nghĩa là gì.
Bắt đầu với kịch bản phổ biến nhất và giữ đơn giản:
Yêu cầu tạo → quản lý phê duyệt → procurement rà soát → PO phát hành → hàng nhận → đóng yêu cầu.
Với mỗi bước, nêu ai làm, họ cần thấy gì, và quyết định họ đưa ra. Đây là hành trình cơ bản và giúp ngăn v1 trở thành nơi chứa mọi ngoại lệ.
Phê duyệt mua thường thất bại vì yêu cầu đến mà thiếu thông tin. Định nghĩa các trường bắt buộc từ đầu (và trường tùy chọn), ví dụ:
Cũng định nghĩa quy tắc xác thực: tệp đính kèm bắt buộc vượt ngưỡng, trường số, và liệu giá có được chỉnh sau khi gửi không.
Ghi rõ các ngoại lệ để đội có thể giao nhanh. Những thứ thường loại trừ v1: sự kiện sourcing đầy đủ (RFP), chấm điểm nhà cung cấp phức tạp, quản lý vòng đời hợp đồng, và tự động đối chiếu 3 bên.
Tạo backlog đơn giản với tiêu chí chấp nhận rõ ràng:
Điều này giữ kỳ vọng thực tế và cho bạn kế hoạch xây dựng khả thi.
Quy trình mua thành công hay thất bại phụ thuộc vào tính rõ ràng của dữ liệu. Nếu các đối tượng và mối quan hệ sạch sẽ, phê duyệt, báo cáo và tích hợp sẽ đơn giản hơn nhiều.
Ít nhất, mô hình hoá các thực thể sau:
Giữ tổng PR được tính từ line item (và thuế/vận chuyển), thay vì chỉnh tay, để tránh sai lệch.
Yêu cầu thực tế thường gom các mục cần approver khác nhau hoặc ngân sách khác nhau. Thiết kế cho:
Cách thực tế là có trạng thái header cho PR cộng trạng thái độc lập cho từng dòng, rồi rollup trạng thái để requester nhìn thấy.
Nếu cần độ chính xác kế toán, lưu cost center, project, và GL code ở mức dòng (không chỉ trên PR), vì chi tiêu thường được ghi nhận theo dòng.
Thêm trường thuế chỉ khi bạn có thể định nghĩa quy tắc rõ ràng (ví dụ: thuế suất, loại thuế, cờ tính thuế đã bao gồm hay chưa).
Báo giá và hợp đồng là phần của câu chuyện kiểm toán. Lưu tệp như đối tượng liên kết tới PR và/hoặc dòng với metadata (loại, người tải lên, timestamp).
Xác định quy tắc lưu giữ sớm (ví dụ: giữ 7 năm; xóa theo yêu cầu nhà cung cấp chỉ khi pháp lý cho phép) và nơi lưu file (cơ sở dữ liệu, object storage, hay hệ thống quản lý tài liệu).
Vai trò và quyền rõ ràng ngăn việc đẩy qua lại phê duyệt và làm cho bản ghi kiểm toán có ý nghĩa. Bắt đầu bằng cách đặt tên những người tham gia, sau đó chuyển đổi thành những gì họ có thể làm trong app.
Phần lớn đội procurement có thể bao phủ 90% trường hợp với năm vai trò:
Định nghĩa quyền như hành động, không phải chức danh, để bạn có thể phối hợp sau này:
Cũng quyết định quy tắc ở mức trường (ví dụ requester chỉnh mô tả/đính kèm nhưng không được chỉnh GL; tài chính chỉnh mã nhưng không chỉnh số lượng/giá).
Mỗi yêu cầu nên có:
Điều này tránh yêu cầu bị bỏ mặc và làm rõ ai cần hành động tiếp.
Mọi người đi nghỉ. Xây ủy quyền với ngày bắt đầu/kết thúc, và ghi hành động là “Đã phê duyệt bởi Alex (ủy quyền từ Priya)” để giữ trách nhiệm.
Với phê duyệt, ưu tiên phê duyệt theo tên (dễ truy ra). Dùng hộp thư chung chỉ cho các bước hàng đợi đội (ví dụ “Procurement Team”), và vẫn yêu cầu một cá nhân nhận và phê duyệt để một người chịu trách nhiệm được ghi lại.
Ứng dụng mua sắm thành công hay thất bại dựa vào tốc độ người dùng gửi yêu cầu và khả năng approver nói “đồng ý” hoặc “không” một cách chắc chắn. Hướng tới ít màn hình, ít trường, ít thao tác—nhưng vẫn thu thập đủ thông tin Finance và Procurement cần.
Dùng form hướng dẫn, thích ứng dựa trên lựa chọn của requester (danh mục, loại nhà cung cấp, hợp đồng vs mua một lần). Điều này giữ form ngắn và giảm trao đổi lại.
Thêm mẫu cho các mua phổ biến (gói phần mềm, laptop, dịch vụ contractor) để tự điền gợi ý GL/cost center, tệp bắt buộc, và chuỗi approver dự kiến. Mẫu cũng chuẩn hóa mô tả, cải thiện báo cáo sau này.
Dùng xác thực nội tuyến và kiểm tra hoàn thành (ví dụ thiếu báo giá, mã ngân sách, hoặc ngày giao) trước khi gửi. Hiện yêu cầu sớm, không chỉ báo lỗi sau khi gửi.
Approver nên vào một hàng đợi sạch với những thông tin cốt lõi: số tiền, nhà cung cấp, cost center, requester và ngày hạn. Sau đó cung cấp ngữ cảnh khi cần:
Giữ bình luận có cấu trúc: cho phép lý do nhanh khi từ chối (ví dụ, “thiếu báo giá”) kèm text tự do tùy chọn.
Người dùng tìm được yêu cầu theo trạng thái, cost center, nhà cung cấp, requester, khoảng ngày và số tiền. Lưu bộ lọc thường dùng như “Chờ tôi” hoặc “Đang chờ > $5,000”.
Nếu phê duyệt xảy ra ở hành lang hoặc giữa các cuộc họp, thiết kế cho màn hình nhỏ: vùng bấm lớn, tóm tắt tải nhanh, xem trước tệp. Tránh workflows yêu cầu chỉnh sửa kiểu bảng tính trên mobile—chuyển các tác vụ đó về desktop.
Định tuyến phê duyệt là hệ thống điều phối giao thông của ứng dụng. Làm tốt thì quyết định nhất quán và nhanh; làm kém thì tạo nghẽn và thủ thuật.
Hầu hết quy tắc phê duyệt có thể biểu diễn bằng vài chiều: những đầu vào phổ biến gồm:
Giữ phiên bản đầu đơn giản: dùng tập quy tắc nhỏ nhất che được phần lớn yêu cầu, rồi thêm các trường hợp cạnh khi có dữ liệu thực.
Một số phê duyệt phải theo thứ tự (manager → chủ ngân sách → procurement), trong khi số khác có thể song song (bảo mật + pháp lý). Hệ thống của bạn nên hỗ trợ cả hai mẫu và hiển thị cho requester biết ai đang chặn yêu cầu.
Phân biệt giữa:
Quy trình thực tế cần cơ chế an toàn:
Không gì làm mất tinh thần bằng phải phê duyệt lại bất ngờ—hoặc phê duyệt vẫn còn hiệu lực nhưng lẽ ra phải chạy lại.
Các kích hoạt đặt lại phê duyệt phổ biến gồm thay đổi giá, số lượng, nhà cung cấp, danh mục, cost center, hoặc địa điểm giao hàng. Quyết định thay đổi nào cần reset toàn bộ, thay đổi nào chỉ cần một số approver xác nhận lại, và thay đổi nào chỉ cần ghi nhận mà không khởi động lại chuỗi phê duyệt.
Ứng dụng mua sắm tạo cảm giác nhanh khi mọi người luôn biết bước tiếp theo. Thông báo và theo dõi trạng thái giảm việc đuổi hỏi, trong khi bản ghi kiểm toán bảo vệ bạn trong tranh chấp, kiểm toán tài chính và kiểm tra tuân thủ.
Dùng một tập trạng thái nhỏ, dễ hiểu và đồng nhất trên PR, phê duyệt, và đơn hàng. Một bộ trạng thái điển hình:
Cụ thể về chuyển trạng thái. Ví dụ, một yêu cầu không nên nhảy từ Draft sang Ordered mà không qua Submitted và Approved.
Bắt đầu với email + in‑app và chỉ thêm chat nếu đó là công cụ họ dùng hàng ngày.
Tránh spam bằng cách gộp nhắc (ví dụ bản tóm tắt hàng ngày) và chỉ leo thang khi phê duyệt quá hạn.
Ghi lại lịch sử chống giả mạo của các hành động chính:
Nhật ký này nên dễ đọc cho kiểm toán nhưng cũng hữu ích cho nhân viên. Một tab “History” trên mỗi yêu cầu thường ngăn được chuỗi email dài.
Bắt buộc bình luận cho một số hành động, như Reject hoặc Request changes, và cho các ngoại lệ (ví dụ phê duyệt vượt ngân sách). Lưu lý do cùng hành động trong bản ghi kiểm toán để không bị mất trong tin nhắn riêng tư.
Tích hợp là thứ khiến ứng dụng mua sắm trở nên thực sự hữu dụng cho doanh nghiệp. Nếu mọi người vẫn phải gõ lại chi tiết nhà cung cấp, ngân sách và số PO, tỷ lệ áp dụng sẽ giảm nhanh.
Bắt đầu bằng việc quyết định công cụ nào là hệ thống lưu trữ sự thật, và coi app của bạn như lớp workflow đọc/ghi với chúng.
Rõ ràng nơi “sự thật” nằm:
Tài liệu hóa app cần gì từ mỗi nguồn (chỉ đọc hay có ghi trở lại), và ai chịu trách nhiệm chất lượng dữ liệu.
Lên kế hoạch SSO sớm để quyền và bản ghi kiểm toán ánh xạ tới danh tính thực.
Khớp phương pháp với khả năng hệ thống đối tác:
Quyết định thứ gì cần thời gian thực (SSO login, xác thực nhà cung cấp) vs lên lịch (làm mới ngân sách vào ban đêm).
Thiết kế cho lỗi: retry có backoff, cảnh báo admin rõ ràng, và báo cáo đối chiếu để tài chính xác nhận tổng giữa các hệ thống. Một timestamp “last synced at” trên bản ghi chính tránh nhầm lẫn và ticket hỗ trợ.
Bảo mật không phải tính năng “sau này” cho ứng dụng mua sắm. Bạn xử lý chi tiết nhà cung cấp, điều khoản hợp đồng, ngân sách và phê duyệt có thể ảnh hưởng đến dòng tiền và rủi ro. Một số quyết định nền tảng sớm sẽ tránh viết lại đau đớn khi tài chính hay kiểm toán tham gia.
Bắt đầu bằng phân loại dữ liệu nhạy cảm và kiểm soát nó rõ ràng. Đặt quyền cho các trường như thông tin ngân hàng nhà cung cấp, mức giá đã đàm phán, tệp hợp đồng và dòng ngân sách nội bộ.
Trong nhiều đội, requester chỉ thấy những gì họ cần để gửi và theo dõi yêu cầu, trong khi procurement và finance thấy được giá và dữ liệu master. Dùng kiểm soát truy cập theo vai trò với chính sách deny‑by‑default cho trường rủi ro cao, và cân nhắc che bớt (ví dụ hiển thị 4 chữ số cuối tài khoản) thay vì lộ toàn bộ.
Mã hóa dữ liệu khi truyền (TLS mọi nơi) và khi lưu (cơ sở dữ liệu và lưu trữ file). Nếu lưu tệp đính kèm (hợp đồng, báo giá), đảm bảo object storage được mã hóa và quyền truy cập có thời hạn.
Xử lý bí mật như dữ liệu production: không hardcode API key; lưu trong secrets manager, xoay vòng, và giới hạn ai có thể đọc. Nếu tích hợp ERP/kế toán, khoá token ở phạm vi nhỏ nhất cần thiết.
Phê duyệt chỉ đáng tin khi có bằng chứng. Ghi lại cả hành động admin và thay đổi quyền, không chỉ sự kiện nghiệp vụ như “đã phê duyệt” hay “bị từ chối.” Ghi ai thay đổi quy tắc phê duyệt, ai gán vai trò, và khi trường ngân hàng nhà cung cấp bị chỉnh sửa.
Làm nhật ký append‑only và có thể tìm theo yêu cầu, nhà cung cấp và người dùng, với timestamp rõ ràng.
Lên kế hoạch tuân thủ sớm (hướng tới SOC 2/ISO, quy tắc lưu giữ dữ liệu, và nguyên tắc ít quyền nhất).
Xác định thời hạn lưu trữ yêu cầu, phê duyệt và tệp đính kèm, và cách xử lý xóa (thường “soft delete” với chính sách giữ). Ghi rõ ai là chủ sở hữu dữ liệu: ai phê duyệt truy cập, ai xử lý sự cố, và ai rà soát quyền định kỳ.
Quyết định build vs buy không phải “tốt nhất”—mà là phù hợp. Procurement chạm tới phê duyệt, ngân sách, bản ghi kiểm toán và tích hợp, nên lựa chọn phụ thuộc vào quy trình phức tạp thế nào và cần kết quả nhanh ra sao.
Mua (hoặc cấu hình hệ thống có sẵn) khi:
Xây khi:
Một quy tắc hữu ích: nếu 80–90% nhu cầu khớp với một sản phẩm và tích hợp được chứng minh, hãy mua. Nếu tích hợp khó hoặc quy tắc là cốt lõi hoạt động, xây có thể rẻ về dài hạn.
Giữ ngăn xếp đơn giản và dễ bảo trì:
Nếu muốn tăng tốc đường “xây” mà không cam kết nhiều tháng phát triển tùy chỉnh, nền tảng tạo prototype như Koder.ai có thể giúp bạn tạo mẫu và lặp app tự động qua giao diện chat. Teams thường dùng để nhanh xác thực định tuyến, vai trò và màn hình cốt lõi, rồi xuất mã nguồn khi sẵn sàng chạy trong pipeline của riêng họ. (Cấu hình chuẩn của Koder.ai — React frontend, Go + PostgreSQL backend — cũng phù hợp với yêu cầu độ tin cậy và kiểm toán mà hệ thống procurement thường cần.)
Tự động hóa mua sắm thất bại khi hành động bị chạy đôi lần hoặc trạng thái mơ hồ. Thiết kế cho:
Lên kế hoạch từ ngày đầu cho dev/staging/prod, test tự động trong CI, và deploy đơn giản (container phổ biến).
Thêm giám sát cho:
Nền tảng này giữ luồng đơn hàng hoạt động khi lượng dùng tăng.
Phát hành phiên bản đầu chỉ là một nửa công việc. Nửa còn lại là đảm bảo các đội thực sự chạy quy trình phê duyệt nhanh, chính xác và tự tin—rồi tối ưu dựa trên thực tế.
Hệ thống thường “ổn” trong demo nhưng vỡ trong thực tế. Trước khi triển khai, kiểm thử workflow bằng kịch bản lấy từ yêu cầu và lịch sử PO gần đây.
Bao gồm các trường hợp cạnh như:
Đừng chỉ test định tuyến—test quyền, thông báo và bản ghi kiểm toán end‑to‑end.
Bắt đầu với nhóm nhỏ đại diện cho việc sử dụng điển hình (ví dụ một phòng ban và một chuỗi approver tài chính). Chạy pilot vài tuần, giữ rollout nhẹ nhàng:
Điều này tránh nhầm lẫn toàn tổ chức trong khi bạn tinh chỉnh định tuyến và quy tắc tự động.
Xem quản trị như tính năng sản phẩm. Viết sổ tay ngắn nội bộ bao gồm:
Điều này giữ hoạt động hàng ngày không biến thành công việc kỹ thuật tùy tiện.
Định vài chỉ số và xem xét đều đặn:
Dùng những gì học được để đơn giản hoá form, điều chỉnh quy tắc và cải thiện theo dõi trạng thái.
Nếu bạn đang đánh giá tùy chọn để triển khai ứng dụng mua sắm nhanh, xem /pricing hoặc liên hệ qua /contact.
Nếu bạn muốn xác thực workflow và màn hình trước khi đầu tư xây dựng tùy chỉnh, bạn cũng có thể tạo nguyên mẫu hệ thống yêu cầu mua trong Koder.ai, lặp trong “chế độ lập kế hoạch”, và xuất mã nguồn khi các bên liên quan đồng ý về quy trình.
Bắt đầu bằng cách ghi lại những điểm tắc nghẽn bạn muốn loại bỏ (ví dụ: phê duyệt kẹt trong email, thiếu báo giá, không rõ người chịu trách nhiệm) và gắn mỗi vấn đề với một chỉ số đo được:
Những chỉ số này sẽ là “ngôi sao phương Bắc” khi tranh luận về tính năng.
Giữ giai đoạn 1 hẹp và rõ ràng. Quyết định:
Cũng hãy ghi rõ những gì nằm ngoài phạm vi v1 (ví dụ RFP hoặc quản lý vòng đời hợp đồng) để bạn có thể phát hành mà không chặn mở rộng sau này.
Vẽ sơ đồ những gì thực sự diễn ra hôm nay, không phải chỉ chính sách. Làm ba việc:
Điều này cung cấp đầu vào để bạn xây quy tắc định tuyến khớp với hành vi thực tế.
Biến sơ đồ thành một bộ yêu cầu có thể xây dựng:
Điều này giúp ngăn v1 trở thành nơi chứa mọi trường hợp ngoại lệ.
Tối thiểu, mô hình hoá:
Giữ tổng số dẫn xuất từ line item (cộng thuế/phí vận chuyển) để tránh sai lệch và dễ tích hợp/báo cáo hơn.
Thiết kế để phản ánh thực tế nhiều mặt:
Điều này tránh buộc người dùng phải làm giải pháp tạm khi chỉ một phần yêu cầu cần thay đổi.
Bắt đầu với một tập vai trò nhỏ và mô tả quyền theo hành động:
Thêm quy tắc ở mức trường (ví dụ requester có thể chỉnh mô tả/đính kèm; finance chỉnh GL/cost center) và đảm bảo mỗi yêu cầu luôn có owner và approver hiện tại để tránh mục “mồ côi”.
Xây tính năng ủy quyền có trách nhiệm:
Điều này tránh phê duyệt trở nên khó truy nguyên.
Hướng đến UX ưu tiên quyết định:
Thêm tìm kiếm/lọc mạnh (trạng thái, cost center, nhà cung cấp, requester, số tiền) và thiết kế thuận tiện cho mobile (tóm tắt nhanh, vùng bấm lớn, xem trước tệp).
Đối xử với khả năng kiểm toán như tính năng cốt lõi:
Về tích hợp, xác định hệ thống lưu trữ sự thật (ERP/accounting, vendor master, HR directory), rồi chọn API/webhook/CSV dựa trên khả năng. Thêm cơ chế retry, cảnh báo admin, báo cáo đối chiếu và timestamp “last synced at” để giảm nhầm lẫn.