ONMATE / WEBSITE THEO YÊU CẦU

Website theo yêu cầu

Thiết kế theo quy trình và mục tiêu riêng của doanh nghiệp.

ONMATE phát triển website và ứng dụng web theo yêu cầu về tính năng, vai trò người dùng và hệ thống cần kết nối. Hai bên thống nhất phạm vi, bản mẫu và tiêu chí nghiệm thu trước khi lập trình.

Xem phạm vi dịch vụ Trao đổi nhu cầu

Câu chuyện người dùng

quanly.nhathom.example/yeu-cau/CDL-102

QQuản lý yêu cầuCổng đại lý (mẫu)L

Yêu cầuBảng đợtBáo cáoThành viênCài đặt

CDL-102 · Đặt lại đơn cũ

Phải có · Đợt 1

Là đại lý, tôi muốn đặt lại một đơn cũ chỉ bằng một lần bấm, để không phải chọn lại từng sản phẩm mỗi tháng.

Điều kiện chấp nhận

Khi đại lý bấm Đặt lại ở một đơn cũ, giỏ đơn có đủ các dòng của đơn đó.
Sản phẩm đã ngừng bán không vào giỏ, hệ thống báo tên sản phẩm bị bỏ.
Giá trong giỏ là giá sỉ hiện hành, không phải giá của đơn cũ.
Đại lý chỉ đặt lại được đơn của chính mình.

Ngoài phạm vi

Đặt lại đơn của đại lý khác.
Tự động đặt hàng định kỳ (đợt sau).

Trạng thái: Đã duyệt
Người viết: Hà Trang
Người duyệt: Lan Anh
Ưu tiên: Phải có
Đợt: Đợt 1
Điều kiện: 4/4 đã viết

Luồng nghiệp vụ

Thử gọi API

daily.nhathom.example/tai-lieu-api/thu-goi

AThử APIMôi trường thửL

Tạo đơn

Môi trường thử, không ảnh hưởng đơn thật

POSTdaily.nhathom.example/api/v1/ordersGửi

Header

Authorization: Bearer ••••••••
Content-Type: application/json
Idempotency-Key: 7f3a9c1e-2051

Nội dung gửi

{ "dealer_id": "DL-0147",
  "lines": [ { "sku": "NT-GD-180", "qty": 24 },
             { "sku": "NT-HN-180", "qty": 12 } ] }

201 Tạo mới184 ms · 96 byte

{ "id": "DH-2051", "status": "cho_duyet" }

Chạy tự động

HÀNH TRÌNH TRÊN WEBSITE THEO YÊU CẦU

Website theo yêu cầu tốt bắt đầu từ việc làm rõ nghiệp vụ, rồi mới chọn công nghệ.

Website đi qua nhiều chặng, từ làm rõ yêu cầu tới nghiệm thu. Chọn một chặng để xem việc ở đó.

CHẶNG 01

Làm rõ yêu cầu

Mỗi nhu cầu thành một câu chuyện có điều kiện chấp nhận, và có dòng ghi rõ cái gì chưa làm trong đợt này.

Sáu chặng quay quanh một điểm. Chọn một chặng để đọc chi tiết.

WEBSITE THEO YÊU CẦU

SÁU PHẦN VIỆC

Chọn một phần việc để xem
toàn bộ cách làm.

Mỗi phần việc có màn hình làm việc, đầu vào và cách đo riêng.

Chạm vào một thẻ để đổi nội dung bên dưới.

Đang xemYêu cầu rõ, nghiệm thu dễ

Nội dung của thẻ Yêu cầu rõ, nghiệm thu dễChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Yêu cầu và phạm vi trông như thế nào.

Ba màn hình: danh sách câu chuyện, một câu chuyện và tài liệu phạm vi. Bấm từng mục để xem.

Danh sách theo đợt và ưu tiên

Đợt 1 có 16 câu chuyện, mỗi dòng ghi mã, mức ưu tiên và số điều kiện đã viết. CDL-104 mới viết 3 trên 5 điều kiện nên chờ duyệt.

Đọc tiếp

Chia ưu tiên giúp đợt đầu gọn lại. Việc Có thể, như tải bảng giá PDF, vẫn nằm trong danh sách nhưng chưa tranh chỗ việc cần ngay.

MÔ PHỎNG · SỐ MẪU

quanly.nhathom.example/yeu-cau?dot=1

QQuản lý yêu cầuCổng đại lý (mẫu)L

Yêu cầuBảng đợtBáo cáoThành viênCài đặt

Yêu cầu

Đợt 1: Đặt hàng và duyệt đơn

Câu chuyện đợt 116Đã duyệt13Chờ duyệt2Để đợt sau1

Đợt 1Mọi vai tròMọi mức ưu tiên

Hiển thị 5 trong 16 câu chuyện

Mã	Câu chuyện	Ưu tiên	Điều kiện
CDL-101	Đặt đơn từ danh mục giá sỉ	Phải có	5/5
CDL-102	Đặt lại đơn cũ bằng một lần bấm	Phải có	4/4
CDL-103	Duyệt hoặc từ chối đơn trong vùng	Phải có	6/6
CDL-104	Xem công nợ hiện tại	Nên có	3/5
CDL-105	Tải bảng giá dạng PDF	Có thể	Chưa viết

Câu chuyện CDL-101 theo mẫu “Là…, tôi muốn…, để…”: một câu nói rõ ai cần gì, vì sao, chưa nói cách làm.
Điều kiện 3/5: CDL-104 mới viết 3 trên 5 điều kiện nên chưa duyệt. Chưa đủ điều kiện thì chưa giao người làm.
Ưu tiên Có thể: tải bảng giá PDF để đợt sau. Chia ba mức giúp đợt 1 chỉ gồm việc cần ngay.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:Atlassian: câu chuyện người dùng ↗Atlassian: điều kiện chấp nhận ↗

LÀM NHƯ THẾ NÀO

Năm bước viết yêu cầu.

Bắt đầu từ cách làm thật. Câu chuyện đủ điều kiện, có người duyệt mới làm.

01Ngồi cùng người làm nghiệp vụ, xem quy trình đang chạy: biểu mẫu, bảng tính, tin nhắn họ dùng.
02Viết từng chức năng thành câu chuyện “Là…, tôi muốn…, để…” rồi gom theo đợt và mức ưu tiên.
03Với mỗi câu chuyện, viết điều kiện chấp nhận chỉ có đúng hoặc sai, kèm phần ngoài phạm vi.
04Người nghiệp vụ đọc và duyệt từng câu chuyện. Câu chưa đủ điều kiện thì chưa giao cho người làm.
05Chốt phạm vi từng đợt thành tài liệu có số phiên bản. Thay đổi sau đó ghi riêng.

Bạn đưa vào

Quy trình và biểu mẫu đang dùng
Bảng tính, danh sách đang quản lý
Người làm nghiệp vụ sẽ duyệt
Chỗ đang vướng hoặc hay sai

Câu chuyện, điều kiện chấp nhận, phạm viONMATE cùng doanh nghiệp

Bạn nhận lại

Câu chuyện chia đợt, điều kiện chấp nhận, việc ngoài phạm vi và tài liệu phạm vi có số phiên bản.

Tài liệu tham khảo:Atlassian: câu chuyện người dùng ↗Scrum Guide: định nghĩa hoàn thành ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để viết yêu cầu.

Cần quy trình đang chạy và một người đủ quyền nói “đúng” hay “chưa đúng”.

NGUYÊN TẮC

Mỗi dòng một câu chuyện, kèm điều kiện chấp nhận và người duyệt. Điều kiện phải kiểm được bằng thử; “dễ dùng” chưa phải điều kiện.

ĐẶC TẢ YÊU CẦU · MẪU

docs.google.com/spreadsheets

nhathom-dac-ta-yeu-cauTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Mã	Câu chuyện	Điều kiện chấp nhận	Ưu tiên	Người duyệt
2	CDL-101	Đại lý đặt đơn từ danh mục giá sỉ	Giỏ đủ dòng đã chọn, giá là giá sỉ hiện hành	Phải có	Lan Anh
3	CDL-102	Đại lý đặt lại đơn cũ bằng một lần bấm	Sản phẩm ngừng bán bị bỏ khỏi giỏ và báo tên	Phải có	Lan Anh
4	CDL-103	Kinh doanh duyệt hoặc từ chối đơn trong vùng	Từ chối phải có lý do, đại lý nhận được lý do	Phải có	Lan Anh
5	CDL-104	Đại lý xem công nợ hiện tại	Mới viết 3 trên 5 điều kiện	Nên có	Chờ duyệt
6	CDL-105	Đại lý tải bảng giá dạng PDF	Chưa viết, để đợt sau	Có thể	—

Đợt 1Ngoài phạm vi

Điều kiện CDL-103: từ chối phải có lý do và đại lý nhận được. Hai vế đều thử được, khỏi tranh cãi nghiệm thu.
CDL-104 chờ duyệt: mới viết 3 trên 5 điều kiện. Chưa đủ thì chưa giao người làm, kẻo hai bên hiểu khác nhau.
CDL-105 để đợt sau: ghi rõ chưa viết điều kiện và chưa làm. Việc để đợt sau vẫn nằm trong bảng, không bị quên.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Mỗi dòng một câu chuyện

Ai, muốn gì, để làm gì

Điều kiện kiểm được

Đúng hoặc sai, không chung chung

Ghi cả ngoài phạm vi

Ranh giới rõ từ đầu

Có người duyệt

Tên người, không phải bộ phận

Bộ tài nguyên4 mục

TệpBiểu mẫu, bảng tính đang dùngBản thật, đã xóa dữ liệu nhạy cảm.
KháchNgười làm nghiệp vụNgười hiểu quy trình, người duyệt từng đợt.
BảngVai trò và số ngườiMỗi vai trò mấy người, cần thấy gì.
KháchNhững lần từng saiĐơn thất lạc, giao nhầm, tính sai.

Xem đủ thông số và ghi chú

Nguồn: Câu chuyện người dùng Atlassian mô tả câu chuyện người dùng là một mô tả ngắn về chức năng, viết từ góc nhìn của người sẽ dùng nó, thường theo mẫu Là…, tôi muốn…, để….
Nguồn: Điều kiện chấp nhận Điều kiện chấp nhận là những điều phải đúng để câu chuyện được coi là xong, nên viết sao cho kiểm được bằng cách thử. Scrum Guide gọi mức xong chung của nhóm là Definition of Done.
Lưu ý: Thay đổi sau khi chốt là chuyện bình thường Thay đổi không xấu, nhưng cần đi qua danh sách thay đổi kèm ảnh hưởng tới thời gian để hai bên cùng chọn làm ngay, để đợt sau hay bỏ.

Tài liệu tham khảo:Atlassian: câu chuyện người dùng ↗Atlassian: điều kiện chấp nhận ↗

ĐO ĐIỀU GÌ

Đo bằng số thay đổi sau khi chốt.

Yêu cầu tốt thể hiện ở số thay đổi giữa dự án. Báo cáo cho biết câu chuyện nào có điều kiện.

CẦN ĐO

Thay đổi dồn vào một tuần thường báo hiệu một nhóm yêu cầu chưa rõ.

BÁO CÁO YÊU CẦU · SỐ MẪU

quanly.nhathom.example/bao-cao/yeu-cau

QQuản lý yêu cầuCổng đại lý (mẫu)L

Yêu cầuBảng đợtBáo cáoThành viênCài đặt

Báo cáo yêu cầu

Cập nhật 07/10/2026

Tổng quan

Câu chuyện trong phạm vi42Có điều kiện chấp nhận42Ngoài phạm vi9Thay đổi sau khi chốt5

Thay đổi sau khi chốt, theo tuần

Tuần 10
Tuần 21
Tuần 32
Tuần 41
Tuần 51
Tuần 60

Thay đổi gần đây

Mã	Thay đổi	Đề xuất	Ảnh hưởng
CDL-087	Thêm điều kiện: đơn tối thiểu 12 hộp	Minh Tuấn	+0,5 ngày
CDL-061	Đổi người duyệt sang Thanh Bình	Lan Anh	Không đổi
CDL-044	Bỏ trường fax khỏi hồ sơ đại lý	Hà Trang	−0,2 ngày

Tổng quan: 42 câu chuyện đều có điều kiện chấp nhận, 9 việc ngoài phạm vi, 5 thay đổi sau khi chốt.
Tuần 3 có 2 thay đổi, cao nhất. Tuần nhiều thay đổi thì hỏi vì sao, thường do yêu cầu chưa rõ.
Ảnh hưởng +0,5 ngày: mỗi thay đổi ghi kèm thời gian tăng thêm. Đơn tối thiểu 12 hộp thêm nửa ngày kiểm thử.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Câu chuyện có điều kiện chấp nhận	Mọi câu chuyện trong đợt đang làm	Có câu chuyện chưa đủ điều kiện mà đã giao
Thay đổi sau khi chốt	Ít, và đều có ảnh hưởng ghi rõ	Tăng đột ngột trong một tuần
Việc ngoài phạm vi	Có danh sách và có người xác nhận	Có việc phát sinh mà chưa ghi vào đâu
Ảnh hưởng tới thời gian	Hai bên đã đồng ý trước khi làm	Cộng dồn mà chưa ai báo

CÁCH ĐỌC

Mở Báo cáo yêu cầu, xem bốn con số đầu, rồi biểu đồ theo tuần và bảng thay đổi gần đây để biết thay đổi nào làm đổi thời gian.

LƯU Ý

Số liệu không cho biết yêu cầu “đúng”; chỉ người làm nghiệp vụ biết.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:Scrum Guide: định nghĩa hoàn thành ↗Atlassian: điều kiện chấp nhận ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Quy trình đang chạy bằng bảng tính và tin nhắn

Bắt đầu từ việc xem người ta đang làm gì, chưa vội viết chức năng.

Xem quy trình thật
Gom biểu mẫu và bảng tính
Viết câu chuyện theo vai trò
Người nghiệp vụ duyệt

Đã có đặc tả nhưng thiếu điều kiện chấp nhận

Giữ lại đặc tả, bổ sung điều kiện cho từng chức năng theo mức ưu tiên.

Đọc đặc tả hiện có
Chọn các chức năng Phải có
Viết điều kiện chấp nhận
Thống nhất phần ngoài phạm vi

Dự án đang bị phát sinh liên tục

Dừng lại ghi danh sách thay đổi, rồi tách phần đã chốt với phần chưa chốt.

Liệt kê mọi thay đổi gần đây
Đánh giá ảnh hưởng từng thay đổi
Chốt lại phạm vi đợt hiện tại
Đưa phần còn lại sang đợt sau

DẤU HIỆU

Làm xong rồi mới thấy hai bên hiểu khác nhau

Chỉ số	Giá trị
Điều kiện đã viết	3 trên 5
Trạng thái	Chờ duyệt
Việc cần làm	Viết đủ điều kiện và duyệt trước khi giao

KIỂM TRA

Câu chuyện chỉ có tiêu đề, chưa có điều kiện chấp nhận.

Đọc tiếp

Viết điều kiện kiểm được trước khi giao làm.

DẤU HIỆU

Nghiệm thu bị tranh cãi

Chỉ số	Giá trị
Cách viết	Đại lý đặt hàng dễ dùng
Kiểm bằng cách	Không có cách nào
Việc cần làm	Viết: bấm Đặt lại thì giỏ có đủ dòng của đơn cũ

KIỂM TRA

Điều kiện viết chung chung như “dễ dùng” nên không kiểm được.

Đọc tiếp

Đổi thành hành động và kết quả cụ thể.

DẤU HIỆU

Việc “nhỏ” thêm vào liên tục

Chỉ số	Giá trị
Thay đổi chưa ghi	Thêm điều kiện đơn tối thiểu 12 hộp
Ảnh hưởng	Thêm 0,5 ngày kiểm thử
Việc cần làm	Ghi vào danh sách thay đổi và hỏi người duyệt

KIỂM TRA

Thay đổi nhỏ không được ghi nên không ai tính ảnh hưởng.

Đọc tiếp

Mọi thay đổi đi qua danh sách thay đổi.

Tài liệu tham khảo:Atlassian: điều kiện chấp nhận ↗Scrum Guide: định nghĩa hoàn thành ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Mỗi chức năng có câu chuyện viết theo mẫu Là…, tôi muốn…, để… kèm tên người viết và người duyệtMỗi câu chuyện có điều kiện chấp nhận kiểm được bằng cách thử, không có điều kiện chỉ ghi “dễ dùng” hay “nhanh”Có danh sách việc ngoài phạm vi và người nghiệp vụ đã đọcCâu chuyện được chia theo đợt và theo ưu tiên Phải có, Nên có, Có thểCác giả định có tên người xác nhận và hạn xác nhậnTài liệu phạm vi có số phiên bản và ngày duyệtThay đổi sau khi chốt được ghi kèm ảnh hưởng tới thời gian và người đề xuấtChỉ giao cho người làm những câu chuyện đã đủ điều kiện chấp nhận

Tài liệu tham khảo:Atlassian: câu chuyện người dùng ↗Scrum Guide: định nghĩa hoàn thành ↗

Nội dung của thẻ Mỗi người đúng phần của mìnhChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Vai trò và phân quyền trông như thế nào.

Ba màn hình: danh sách vai trò, ma trận quyền và trang không có quyền. Bấm từng mục để xem.

Năm vai trò, mỗi vai một phạm vi

Mỗi thẻ ghi số người, việc làm và mức xem dữ liệu: của mình, theo vùng, theo kho hoặc tất cả. Cổng có 5 vai trò và 23 người dùng.

Đọc tiếp

Số người được ghi để biết vai trò nào đông và cần kiểm chặt. Quản trị chỉ có 1 người vì đây là vai trò mạnh nhất.

MÔ PHỎNG · SỐ MẪU

daily.nhathom.example/quan-tri/vai-tro

NCổng đại lýQuản trịL

Đơn hàngĐại lýSản phẩmVai tròNhật kýTích hợpBáo cáo

Vai trò

5 vai trò · 23 người dùng

Đại lý14 người

Đặt đơn, xem đơn và công nợ của chính mình.

Xem đượcCủa mình

Kinh doanh4 người

Nhân viên kinh doanh duyệt hoặc từ chối đơn, xem đại lý trong vùng.

Xem đượcTheo vùng

Thủ kho2 người

Soạn hàng, giao hàng, cập nhật tồn kho.

Xem đượcTheo kho

Kế toán2 người

Xuất hóa đơn, đối chiếu thanh toán.

Xem đượcTất cả

Quản trị1 người

Quản lý người dùng và cấu hình.

Xem đượcTất cả

Đại lý: 14 người, chỉ thấy đơn và công nợ của chính mình. Vai trò đông nhất nên quyền được kiểm chặt nhất.
Kinh doanh: 4 người, thấy đại lý trong vùng được giao. “Theo vùng” nghĩa là lọc cả danh sách, không chỉ ẩn nút bấm.
Quản trị: 1 người, quản lý người dùng và cấu hình. Vai trò mạnh nhất nên ít người nhất.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Ma trận quyền một trang

Hàng là chức năng, cột là vai trò. Ô ghi mức được làm, dấu gạch là không có quyền. Ghi chú bên dưới giải thích Mình, Vùng và Kho.

Đọc tiếp

Ma trận là bản gốc. Màn hình, máy chủ và ca kiểm thử đều làm theo bảng này, nên muốn đổi quyền thì sửa bảng trước.

MÔ PHỎNG · SỐ MẪU

daily.nhathom.example/quan-tri/quyen

NCổng đại lýQuản trịL

Đơn hàngĐại lýSản phẩmVai tròNhật kýTích hợpBáo cáo

Quyền theo vai trò

Máy chủ kiểm tra từng yêu cầu

Chức năng	Đại lý	Kinh doanh	Thủ kho	Kế toán	Quản trị
Xem đơn hàng	Mình	Vùng	Kho	Tất cả	Tất cả
Duyệt đơn	—	Vùng	—	—	—
Cập nhật tồn kho	—	—	Kho	—	Có
Xuất hóa đơn	—	—	—	Có	—
Quản lý người dùng	—	—	—	—	Có

“—” là không có quyền. Mình: chỉ bản ghi của chính họ. Vùng: đại lý trong vùng phụ trách. Kho: đúng kho được giao. Giới hạn áp dụng cho cả bản ghi được xem, không chỉ chức năng.

Duyệt đơn: chỉ kinh doanh, theo vùng. Thủ kho và kế toán thấy đơn nhưng không có nút duyệt.
Xuất hóa đơn: chỉ kế toán. Việc soạn hàng và việc ra hóa đơn nằm ở hai người khác nhau.
Quản lý người dùng: chỉ quản trị. Thêm người hay đổi vai trò là đổi quyền, nên chỉ một vai trò được làm.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:OWASP: phân quyền ↗MDN: mã 403 Forbidden ↗

LÀM NHƯ THẾ NÀO

Năm bước phân quyền.

Nghĩ quyền ngoài đời trước. Máy chủ quyết định, màn hình chỉ phản ánh.

01Liệt kê vai trò thật trong tổ chức, số người mỗi vai trò, kể cả vai trò quản trị.
02Với mỗi chức năng, hỏi ai được xem, ai được làm và có giới hạn theo bản ghi hay không.
03Vẽ ma trận quyền một trang và cho người nghiệp vụ duyệt trước khi viết mã.
04Máy chủ kiểm quyền từng yêu cầu, lọc danh sách theo bản ghi được xem, không chỉ ẩn nút.
05Ghi nhật ký truy cập, kiểm thử các ca truy cập trái quyền và rà lại quyền sau mỗi đợt.

Bạn đưa vào

Danh sách người dùng theo vai trò
Dữ liệu mỗi vai trò được thấy
Quy định nội bộ về dữ liệu nhạy cảm
Người cấp và thu hồi quyền

Vai trò, ma trận quyền, kiểm tra ở máy chủONMATE cùng doanh nghiệp

Bạn nhận lại

Vai trò, ma trận quyền, kiểm quyền ở máy chủ, nhật ký truy cập và ca thử truy cập trái quyền.

Tài liệu tham khảo:OWASP: phân quyền ↗OWASP: lỗi kiểm soát truy cập ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để phân quyền.

Cần biết ai làm gì ngoài đời trước khi nói quyền trong hệ thống.

NGUYÊN TẮC

Ma trận quyền: hàng là chức năng, cột là vai trò, ô ghi mức được phép. Ghi một lần, màn hình và máy chủ cùng theo.

MA TRẬN QUYỀN · MẪU

docs.google.com/spreadsheets

nhathom-ma-tran-quyenTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E	F
1	Chức năng	Đại lý	Kinh doanh	Thủ kho	Kế toán	Quản trị
2	Xem đơn hàng	Của mình	Theo vùng	Theo kho	Tất cả	Tất cả
3	Duyệt đơn	Không	Theo vùng	Không	Không	Không
4	Cập nhật tồn kho	Không	Không	Theo kho	Không	Có
5	Xuất hóa đơn	Không	Không	Không	Có	Không
6	Quản lý người dùng	Không	Không	Không	Không	Có

Quyền theo vai tròNgười dùng

Duyệt đơn của Kinh doanh: chỉ đơn đại lý trong vùng được giao. “Theo vùng” giới hạn cả danh sách.
Cập nhật tồn kho của Thủ kho: theo kho. Thủ kho kho A không sửa được tồn của kho B dù cùng vai trò.
Quản lý người dùng của Quản trị: một dòng một vai trò. Bảng là bản gốc, màn hình và máy chủ cùng theo.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Quyền tối thiểu

Chưa cần thì chưa cấp

Kiểm ở máy chủ

Không chỉ ẩn nút

Giới hạn theo bản ghi

Của mình, theo vùng, theo kho

Có nhật ký

Trái quyền thì bị ghi lại

Bộ tài nguyên4 mục

BảngDanh sách người dùngTên, vai trò, vùng hoặc kho, quản lý.
KháchQuy định dữ liệu nhạy cảmCông nợ, giá sỉ, hợp đồng: ai xem.
KháchNgười cấp và thu hồi quyềnMột người có tên chịu trách nhiệm.
TệpTrường hợp ngoại lệNgười thay thế, nghỉ việc, đổi vùng.

Xem đủ thông số và ghi chú

Nguồn: Phân quyền ở máy chủ OWASP khuyến nghị kiểm tra quyền ở mọi yêu cầu và từ chối theo mặc định, thay vì dựa vào việc người dùng không thấy nút.
Nguồn: Lỗi kiểm soát truy cập OWASP xếp lỗi kiểm soát truy cập ở nhóm rủi ro đứng đầu của ứng dụng web. Ví dụ điển hình là đổi mã trong địa chỉ để xem bản ghi của người khác.
Lưu ý: Thông báo từ chối không nên nói thừa Phản hồi 403 nên cho biết không có quyền và hướng dẫn liên hệ, không nên mô tả bản ghi đó của ai hay gồm những gì.

Tài liệu tham khảo:OWASP: phân quyền ↗OWASP: lỗi kiểm soát truy cập ↗

ĐO ĐIỀU GÌ

Đo bằng nhật ký truy cập.

Phân quyền đúng thể hiện ở nhật ký: ít yêu cầu bị từ chối, mỗi lần từ chối giải thích được.

CẦN ĐO

Từ chối lặp lại hoặc ngoài giờ làm việc thì cần hỏi lại.

NHẬT KÝ TRUY CẬP · SỐ MẪU

daily.nhathom.example/quan-tri/nhat-ky

NCổng đại lýQuản trịL

Đơn hàngĐại lýSản phẩmVai tròNhật kýTích hợpBáo cáo

Nhật ký truy cập

24 giờ gần nhất

Tổng quan

Yêu cầu12.480Bị từ chối (403)37Đăng nhập sai22Quản trị ngoài giờ1

Sự kiện gần nhất

Giờ	Người dùng	Hành động	Kết quả
09:41	Hương Sen (đại lý)	Xem đơn DH-2048	Từ chối 403
09:38	Minh Tuấn (kinh doanh)	Duyệt đơn DH-2047	Thành công
09:12	Thanh Bình (thủ kho)	Cập nhật tồn kho NT-GD-180	Thành công
02:07	Lan Anh (quản trị)	Đăng nhập từ thiết bị mới	Cần xem
08:55	Hương Sen (đại lý)	Đăng nhập sai mật khẩu	Cảnh báo

Tổng quan: 12.480 yêu cầu, 37 bị từ chối, 22 đăng nhập sai, 1 lần quản trị ngoài giờ. Xem đây đầu tiên.
Từ chối 403: đại lý Hương Sen mở đơn DH-2048 của người khác. Một lần có thể bấm nhầm; lặp lại thì cần hỏi.
Quản trị lúc 02:07, thiết bị mới: đúng quyền nhưng giờ và thiết bị bất thường. Gắn “Cần xem” để hỏi chủ tài khoản.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Yêu cầu bị từ chối (403)	Ít và rải rác	Một người lặp lại nhiều lần
Đăng nhập sai	Vài lần mỗi ngày	Tăng đột ngột trên cùng một tài khoản
Quản trị ngoài giờ	Có lý do và người phụ trách biết	Thiết bị mới mà chưa ai xác nhận
Quyền đang được cấp	Khớp với ma trận	Có người có quyền mà ma trận không ghi

CÁCH ĐỌC

Mở Nhật ký truy cập, xem bốn con số đầu rồi đọc từng dòng Từ chối, Cảnh báo hoặc Cần xem.

Đọc tiếp

Hỏi người phụ trách khi chưa giải thích được.

LƯU Ý

Nhật ký chỉ ghi điều đã xảy ra, không chứng minh không có truy cập trái phép.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:OWASP: ghi nhật ký ↗OWASP: lỗi kiểm soát truy cập ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Hệ thống mới có nhiều vai trò

Vẽ ma trận trước khi dựng màn hình.

Liệt kê vai trò và số người
Vẽ ma trận quyền
Người nghiệp vụ duyệt
Dựng kiểm tra ở máy chủ

Hệ thống đang dùng chung một tài khoản

Tách thành tài khoản riêng theo từng người rồi mới chia quyền.

Lập danh sách người thật
Tạo tài khoản riêng
Gán vai trò vừa đủ
Thu hồi tài khoản dùng chung

Nghi có người xem dữ liệu không thuộc phần mình

Bắt đầu từ nhật ký rồi thử lại bằng tài khoản thật.

Xem nhật ký truy cập
Thử mở dữ liệu trái quyền
Sửa kiểm tra ở máy chủ
Thêm ca kiểm thử để không lặp lại

DẤU HIỆU

Đại lý xem được đơn của đại lý khác

Chỉ số	Giá trị
Cách kiểm	Chỉ kiểm đã đăng nhập
Kết quả khi thử	200 với đơn của người khác
Việc cần làm	Lọc theo đại lý của người đăng nhập, trả 403 nếu không thuộc

KIỂM TRA

Máy chủ chỉ kiểm đã đăng nhập mà chưa kiểm đơn có thuộc người đó không.

Đọc tiếp

Thêm điều kiện theo bản ghi.

DẤU HIỆU

Nút bị ẩn nhưng vẫn gọi được

Chỉ số	Giá trị
Nơi chặn	Chỉ ẩn nút ở màn hình
Cách thử	Gọi thẳng địa chỉ API
Việc cần làm	Kiểm quyền ở máy chủ, rồi viết ca kiểm thử gọi trực tiếp

KIỂM TRA

Quyền chỉ chặn ở màn hình.

Đọc tiếp

Chuyển việc kiểm sang máy chủ cho từng yêu cầu.

DẤU HIỆU

Người đã nghỉ việc vẫn đăng nhập được

Chỉ số	Giá trị
Bước thu hồi tài khoản	Chưa có trong quy trình
Tài khoản còn hoạt động	1 người đã nghỉ
Việc cần làm	Gắn việc thu hồi vào quy trình nghỉ việc

KIỂM TRA

Quy trình nghỉ việc không có bước thu hồi tài khoản.

Đọc tiếp

Thêm bước này và rà danh sách định kỳ.

Tài liệu tham khảo:OWASP: lỗi kiểm soát truy cập ↗OWASP: hướng dẫn kiểm thử bảo mật web ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Có danh sách vai trò thật và số người của từng vai tròMa trận quyền một trang đã được người nghiệp vụ duyệtMáy chủ kiểm quyền ở từng yêu cầu và mặc định từ chốiDanh sách cũng bị lọc theo bản ghi được xem, không chỉ chặn khi mở chi tiếtThông báo từ chối không lộ thông tin về bản ghi bị chặnCó ca kiểm thử truy cập trái quyền, gồm cả gọi trực tiếp địa chỉ APINhật ký ghi từ chối, đăng nhập sai và thao tác quản trị, có người xem định kỳCó quy trình cấp, đổi và thu hồi tài khoản khi nhân sự thay đổi

Tài liệu tham khảo:OWASP: phân quyền ↗OWASP: ghi nhật ký ↗

Nội dung của thẻ Vẽ luồng trước khi viết mãChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Luồng nghiệp vụ trông như thế nào.

Ba màn hình: sơ đồ làn, vòng đời của đơn và bản mẫu bấm được. Bấm từng mục để xem.

Ai làm bước nào, theo thứ tự

Mỗi hàng một vai trò, mỗi ô một bước. Đơn đi từ đại lý sang kinh doanh, kho, kế toán. Ô Duyệt đơn có nhánh Từ chối về Nháp.

Đọc tiếp

Đọc sơ đồ cùng từng người trong luồng. Nếu họ nói “chỗ này không có thật” thì sơ đồ sai, không phải người sai.

MÔ PHỎNG · SỐ MẪU

so-do.nhathom.example/luong/dat-hang

SSơ đồ luồngCổng đại lý (mẫu)L

Từ đặt đơn tới thanh toán

Luồng chính · 4 vai trò

Đại lýTạo đơn nhápGửi đơn

Kinh doanhDuyệt đơn?Từ chối: về NhápĐã duyệt

Thủ khoSoạn hàngGiao hàng

Kế toánXuất hóa đơnĐối chiếu

Ô quyết định: nhân viên kinh doanh duyệt hoặc từ chối. Nhánh từ chối quay về Nháp, đừng bỏ vì hay bị sót.
Soạn hàng: việc của thủ kho, chỉ bắt đầu khi đơn đã duyệt. Ô nằm đúng hàng người làm, rõ ai chịu trách nhiệm.
Đối chiếu: bước cuối của kế toán. Luồng có điểm kết thúc rõ ràng, nếu không đơn sẽ nằm ở đâu đó mãi.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Vòng đời của một đơn hàng

Sáu trạng thái nối bằng mũi tên, thêm hai nhánh Từ chối và Đã hủy. Bảng dưới ghi mỗi lần chuyển do ai làm, cần điều kiện gì.

Đọc tiếp

Mỗi dòng của bảng là một nhóm ca kiểm thử: một ca chuyển khi điều kiện đúng và một ca chuyển khi điều kiện sai.

MÔ PHỎNG · SỐ MẪU

so-do.nhathom.example/luong/trang-thai-don

SSơ đồ luồngCổng đại lý (mẫu)L

Vòng đời của một đơn hàng

6 trạng thái · 2 nhánh rẽ

NhápChờ duyệtĐã duyệtĐang soạnĐã giaoĐã thanh toán

Từ chốiTừ Chờ duyệt, quay về Nháp, có lý doĐã hủyTừ Nháp, Chờ duyệt hoặc Đã duyệt, có lý do

Ai được chuyển trạng thái

Chuyển	Ai làm	Điều kiện
Nháp → Chờ duyệt	Đại lý	Có ít nhất một sản phẩm
Chờ duyệt → Đã duyệt	Kinh doanh	Đại lý còn hạn mức công nợ
Đã duyệt → Đang soạn	Thủ kho	Đủ tồn kho cho mọi dòng
Đã giao → Đã thanh toán	Kế toán	Có chứng từ thanh toán

Chờ duyệt: trạng thái đơn nằm chờ nhân viên kinh doanh. Chỉ có hai đường ra là Đã duyệt hoặc Từ chối.
Từ chối: quay về Nháp, bắt buộc có lý do. Đơn không “biến mất”: mỗi lần đổi đều để lại dấu vết.
Điều kiện “còn hạn mức công nợ”: chỉ khi đúng mới duyệt. Mỗi dòng cần một ca kiểm thử đúng và một ca sai.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:Usability.gov: kiểm thử khả dụng ↗W3C WAI: kiểm tra dữ liệu biểu mẫu ↗

LÀM NHƯ THẾ NÀO

Năm bước vẽ luồng.

Hỏi người đang làm từng bước. Sơ đồ khớp cách làm thật, rồi mới cải tiến.

01Hỏi từng người trong quy trình: nhận gì, làm gì, giao cho ai, kể cả các trường hợp ngoại lệ.
02Vẽ sơ đồ làn với một hàng cho mỗi vai trò và một điểm kết thúc rõ ràng.
03Liệt kê trạng thái của đơn, ai được chuyển và điều kiện chuyển, rồi thêm nhánh từ chối và hủy.
04Dựng bản mẫu bấm được cho luồng chính và các nhánh lỗi, cho người nghiệp vụ thử.
05Ghi lại chỗ người thử vướng, sửa bản vẽ rồi mới đưa luồng đã duyệt cho người làm.

Bạn đưa vào

Người trong quy trình
Biểu mẫu, bảng tính đang đi qua tay
Những lần đơn bị kẹt hoặc sai
Thời gian xử lý mong muốn

Sơ đồ làn, trạng thái, bản mẫuONMATE cùng doanh nghiệp

Bạn nhận lại

Sơ đồ làn của luồng chính, bảng chuyển trạng thái, bản mẫu bấm được và danh sách chỗ người thử vướng.

Tài liệu tham khảo:Usability.gov: kiểm thử khả dụng ↗Atlassian: câu chuyện người dùng ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để vẽ luồng.

Cần người thật đang làm từng bước, không chỉ người quản lý. Họ biết ngoại lệ.

NGUYÊN TẮC

Bảng chuyển trạng thái là hợp đồng của luồng: từ đâu sang đâu, ai làm, điều kiện gì. Chỗ nào chưa rõ là chỗ có người phải đoán.

BẢNG CHUYỂN TRẠNG THÁI · MẪU

docs.google.com/spreadsheets

nhathom-bang-chuyen-trang-thaiTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Từ	Sang	Ai làm	Điều kiện	Sau đó
2	Nháp	Chờ duyệt	Đại lý	Có ít nhất một sản phẩm	Báo nhân viên phụ trách
3	Chờ duyệt	Đã duyệt	Kinh doanh	Đại lý còn hạn mức công nợ	Báo thủ kho
4	Chờ duyệt	Nháp (từ chối)	Kinh doanh	Bắt buộc ghi lý do	Báo đại lý kèm lý do
5	Đã duyệt	Đang soạn	Thủ kho	Đủ tồn kho cho mọi dòng	Báo đại lý đang soạn
6	Đã giao	Đã thanh toán	Kế toán	Có chứng từ thanh toán	Đóng đơn

Chuyển trạng tháiThông báo

Điều kiện duyệt: đại lý còn hạn mức công nợ. Điều kiện nằm trong bảng nên người làm không phải đoán khi viết.
Từ chối: bắt buộc ghi lý do và báo cho đại lý. Thiếu thì đại lý bị trả đơn mà không biết sửa gì.
Đã giao sang Đã thanh toán: cần có chứng từ. Bước cuối chỉ kế toán làm, đơn đóng lại và không đổi nữa.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Một điểm kết thúc

Đơn không nằm mãi giữa chừng

Mỗi lần chuyển có người làm

Và có điều kiện

Có nhánh từ chối

Quay về đâu, ai được báo

Thử trên bản mẫu

Trước khi viết mã

Bộ tài nguyên4 mục

KháchNgười làm từng bướcMỗi vai trò một người ngồi vẽ cùng.
TệpBiểu mẫu đang đi qua tayPhiếu giấy, bảng tính, tin nhắn.
BảngNhững lần đơn bị kẹtĐơn chờ lâu, giao nhầm, tính sai.
KháchThời gian xử lý mong muốnDuyệt bao lâu, giao bao lâu.

Xem đủ thông số và ghi chú

Nguồn: Nhánh lỗi cũng là một phần của luồng Hướng dẫn kiểm tra dữ liệu biểu mẫu của W3C WAI nói thông báo lỗi nên chỉ ra chỗ sai và cách sửa. Nhánh vượt hạn mức trong bản mẫu cũng cần như vậy.
Nguồn: Cho người dùng thật thử Usability.gov mô tả kiểm thử khả dụng là để người dùng thật thử làm việc thật rồi quan sát chỗ họ vướng, thay vì chỉ hỏi họ nghĩ gì.
Lưu ý: Đừng chỉ vẽ cách làm lý tưởng Sơ đồ chỉ có cách làm mong muốn sẽ không khớp với thực tế. Ghi cả việc làm tay hoặc làm ngoài hệ thống rồi mới quyết định giữ hay bỏ.

Tài liệu tham khảo:Atlassian: câu chuyện người dùng ↗W3C WAI: kiểm tra dữ liệu biểu mẫu ↗

ĐO ĐIỀU GÌ

Đo bằng thời gian xử lý của đơn.

Luồng tốt thì đơn đi nhanh, ít kẹt. Báo cáo cho biết trạng thái nào lâu nhất, đơn nào quá hạn.

CẦN ĐO

So các trạng thái với nhau trước; chỗ lâu nhất thường không phải chỗ ta đoán.

THỜI GIAN XỬ LÝ · SỐ MẪU

daily.nhathom.example/quan-tri/bao-cao/thoi-gian

NCổng đại lýQuản trịL

Đơn hàngĐại lýSản phẩmVai tròNhật kýTích hợpBáo cáo

Thời gian xử lý đơn

30 ngày gần nhất

Từ gửi đơn đến giao hàng

Trung bình2,4 ngàyĐơn quá hạn duyệt3Đơn bị trả lại7%

Thời gian đơn nằm ở từng trạng thái

Chờ duyệt0,4 ngày
Đã duyệt, chờ soạn0,3 ngày
Đang soạn0,9 ngày
Đang giao0,8 ngày

Đơn đang nằm lâu

Đơn	Trạng thái	Người xử lý	Đã chờ
DH-2041	Chờ duyệt	Minh Tuấn	3 ngày
DH-2043	Đang soạn	Thanh Bình	2 ngày
DH-2046	Chờ duyệt	Minh Tuấn	1 ngày

Trung bình 2,4 ngày, từ lúc đại lý gửi đơn tới lúc giao. Có số này mới biết quy trình nhanh hay chậm hơn.
Đang soạn 0,9 ngày: trạng thái lâu nhất, tô vàng. Chỗ nghẽn là kho, không phải khâu duyệt như mọi người vẫn đoán.
Đơn nằm lâu: DH-2041 chờ duyệt 3 ngày. Danh sách này đưa việc cần xử lý lên đầu, kèm tên người đang giữ.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Thời gian trung bình từ gửi đến giao	Ngắn dần sau mỗi đợt cải tiến	Dài ra mà chưa rõ lý do
Thời gian ở từng trạng thái	Cân đối giữa các bước	Một bước chiếm phần lớn
Đơn quá hạn duyệt	Ít và có người phụ trách	Tăng đều qua các tuần
Đơn bị trả lại	Giảm khi lý do được báo rõ	Cao mà lý do không được ghi

CÁCH ĐỌC

Mở báo cáo Thời gian xử lý, nhìn thanh dài nhất ở phần từng trạng thái, rồi mở danh sách đơn nằm lâu để biết đơn nào, ai đang giữ.

LƯU Ý

Thời gian ngắn chưa chắc tốt: duyệt vội làm tăng đơn bị trả lại.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:Atlassian: thời gian chu trình ↗Usability.gov: kiểm thử khả dụng ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Quy trình chưa từng được vẽ ra

Bắt đầu từ việc ngồi với từng người rồi mới vẽ.

Phỏng vấn từng vai trò
Vẽ sơ đồ làn
Liệt kê trạng thái
Thử bằng bản mẫu

Có sơ đồ nhưng hay bị bỏ qua

So sơ đồ với cách làm thật ở vài đơn gần đây.

Chọn 5 đơn gần đây
Theo dõi từng bước thật
Ghi chỗ khác sơ đồ
Sửa sơ đồ hoặc sửa cách làm

Đơn hay bị kẹt mà không rõ ở đâu

Đo thời gian từng trạng thái để thấy chỗ nghẽn.

Ghi giờ chuyển trạng thái
Xem thanh dài nhất
Hỏi người phụ trách trạng thái đó
Sửa một điều kiện rồi đo lại

DẤU HIỆU

Đơn bị từ chối rồi biến mất

Chỉ số	Giá trị
Nhánh từ chối	Không có đích
Đại lý nhận được	Không có thông báo
Việc cần làm	Quay về Nháp và báo đại lý kèm lý do

KIỂM TRA

Nhánh từ chối không có nơi quay về và không báo ai.

Đọc tiếp

Cho đơn quay về Nháp và bắt buộc ghi lý do.

DẤU HIỆU

Hai người cùng làm một bước

Chỉ số	Giá trị
Bước Xuất hóa đơn	Kho và kế toán cùng làm
Hậu quả	Có đơn bị xuất hai lần
Việc cần làm	Giao cho Kế toán, Kho chỉ báo đã giao

KIỂM TRA

Sơ đồ không ghi rõ ai chịu trách nhiệm.

Đọc tiếp

Đặt mỗi bước vào đúng một hàng vai trò.

DẤU HIỆU

Người dùng không biết đơn đang ở đâu

Chỉ số	Giá trị
Màn hình sau khi gửi	Chỉ ghi “Thành công”
Câu hỏi của đại lý	Đơn đã tới ai chưa?
Việc cần làm	Hiện mã đơn, trạng thái Chờ duyệt và nút Theo dõi đơn

KIỂM TRA

Màn hình sau khi gửi không cho biết trạng thái và bước kế tiếp.

Đọc tiếp

Thêm trạng thái và nút theo dõi.

Tài liệu tham khảo:Usability.gov: kiểm thử khả dụng ↗Atlassian: thời gian chu trình ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Có sơ đồ làn với một hàng cho mỗi vai trò và một điểm kết thúc rõ ràngCó bảng chuyển trạng thái ghi người làm, điều kiện và việc kế tiếpCó nhánh từ chối và hủy, nêu rõ quay về đâu và ai được báoMỗi vai trò có ít nhất một người thật đã đọc sơ đồCó bản mẫu bấm được cho luồng chính và nhánh lỗiĐã cho người nghiệp vụ thử bản mẫu và ghi lại chỗ họ vướngCác việc đang làm tay hoặc ngoài hệ thống được ghi lại, không bị bỏ sótCó số đo thời gian xử lý để so sánh trước và sau khi chạy

Tài liệu tham khảo:Usability.gov: kiểm thử khả dụng ↗Atlassian: điều kiện chấp nhận ↗

Nội dung của thẻ Dữ liệu sạch từ lúc nhậpChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Dữ liệu và nhập tệp trông như thế nào.

Ba màn hình: sơ đồ quan hệ, quy tắc bảng và các bước nhập tệp. Bấm từng mục để xem.

Bảng nào nối với bảng nào

Năm bảng với bốn quan hệ một nhiều. Mỗi đơn thuộc một đại lý, mỗi dòng đơn thuộc một đơn và một sản phẩm. Khóa ngoại được đánh dấu FK.

Đọc tiếp

Đơn giá được lưu ngay trong dòng đơn, nên đổi bảng giá sau này không làm đổi đơn cũ và hóa đơn cũ vẫn đúng.

MÔ PHỎNG · SỐ MẪU

dulieu.nhathom.example/quan-he

DQuản trị dữ liệuCổng đại lý (mẫu)L

BảngQuan hệNhập tệpChất lượngCài đặt

Sơ đồ quan hệ

5 bảng · 4 quan hệ

dai_ly

idPK

tentext

ma_so_thuetext

vungenum

han_mucsố

don_hang

idPK

dai_ly_idFK

trang_thaienum

tong_tiensố

dong_don

idPK

don_hang_idFK

san_pham_idFK

so_luongsố

don_giasố

san_pham

idPK

matext

tentext

gia_sisố

ton_khosố

nguoi_dung

idPK

dai_ly_idFK

emailtext

vai_troenum

dai_ly_id trong don_hang: khóa ngoại nối mỗi đơn với đúng một đại lý. Không có đơn nào mồ côi.
don_gia: lưu giá lúc đặt. Bảng giá đổi sau này không đổi đơn cũ, nên hóa đơn và báo cáo cũ vẫn đúng.
dai_ly_id trong nguoi_dung: mỗi người dùng thuộc một đại lý. Nền cho quyền “của mình”: lọc đơn theo đại lý đang đăng nhập.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Quy tắc của từng cột

Bảng dai_ly liệt kê cột, kiểu, quy tắc: bắt buộc, duy nhất, thuộc danh sách hay từ 0. Ghi chú nhắc quy tắc nằm ở cơ sở dữ liệu.

Đọc tiếp

Nhờ vậy nhập tay, nhập tệp hay gọi API đều bị kiểm tra như nhau, không có đường nào lọt dữ liệu sai.

MÔ PHỎNG · SỐ MẪU

dulieu.nhathom.example/bang/dai_ly

DQuản trị dữ liệuCổng đại lý (mẫu)L

BảngQuan hệNhập tệpChất lượngCài đặt

Bảng dai_ly

147 bản ghi

Cột và quy tắc

Cột	Kiểu	Quy tắc
`id`	uuid	Tự sinh, không đổi
`ten`	text	Bắt buộc, tối đa 120 ký tự
`ma_so_thue`	text	Duy nhất, 10 hoặc 13 số
`vung`	enum	Một trong 6 vùng đã khai
`han_muc`	số	Từ 0, đơn vị đồng
`email`	text	Duy nhất, đúng định dạng

Quy tắc nằm ở cơ sở dữ liệu, không chỉ ở màn hình nhập: nhập tay, nhập tệp hay gọi API đều bị kiểm tra như nhau.

ma_so_thue: duy nhất, 10 hoặc 13 số. Cơ sở dữ liệu chặn trùng, nên hai đại lý không thể có cùng một mã.
vung: chỉ nhận 6 vùng đã khai. Gõ tự do sẽ ra “Hồ Chi Minh” và “HCM” cho một nơi, báo cáo sai.
han_muc: từ 0, đơn vị đồng. Đơn vượt hạn mức bị giữ ở Nháp, đúng với điều kiện đã viết trong yêu cầu.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Nhập tệp qua ba bước

Chọn tệp, ghép cột trong tệp với trường của hệ thống rồi kiểm tra. Bước kiểm tra chưa lưu gì, người dùng thấy kết quả trước khi quyết định nhập.

Đọc tiếp

Lưu tệp CSV bằng UTF-8 để giữ dấu tiếng Việt. Dòng đầu mỗi cột được hiện ra để ghép đúng, nhất là khi tên cột khác tên trường.

MÔ PHỎNG · SỐ MẪU

dulieu.nhathom.example/nhap/dai-ly

DQuản trị dữ liệuCổng đại lý (mẫu)L

BảngQuan hệNhập tệpChất lượngCài đặt

Nhập danh sách đại lý

Bước 2 trên 4

Chọn tệp2Ghép cột3Kiểm tra4Nhập

dai-ly-thang-10.csv412 dòng · UTF-8

Ghép cột trong tệp với trường của hệ thống

Cột trong tệp	Dòng đầu	Trường
Tên cửa hàng	Hương Sen	ten
MST	0312345678	ma_so_thue
Khu vực	Hồ Chí Minh	vung
Hạn mức	20.000.000	han_muc
Ghi chú	Khách cũ	Bỏ qua

Kiểm tra trước khi nhậpChưa có gì được lưu

Tệp: 412 dòng, mã hóa UTF-8. UTF-8 giữ nguyên dấu tiếng Việt, tệp lưu sai bảng mã sẽ ra chữ vỡ.
Ghép MST với ma_so_thue: tên cột trong tệp thường khác tên trường. Ghép một lần, hệ thống hiện dòng mẫu để kiểm tra ngay.
Kiểm tra trước khi nhập: chưa lưu gì. Người dùng thấy kết quả và sửa lỗi trước, thay vì nhập hỏng rồi mới biết.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:PostgreSQL: ràng buộc dữ liệu ↗RFC 4180: định dạng tệp CSV ↗

LÀM NHƯ THẾ NÀO

Năm bước dựng dữ liệu.

Quyết định dữ liệu gồm gì và nối ra sao trước khi dựng màn hình.

01Liệt kê những thứ cần ghi nhớ: đại lý, đơn, sản phẩm, người dùng, và ai là chủ từng loại.
02Vẽ quan hệ: cái nào thuộc cái nào, và giá trị nào phải lưu lại lúc đặt, như đơn giá.
03Đặt quy tắc cho từng cột: bắt buộc, duy nhất, danh sách đóng, khoảng giá trị và đơn vị.
04Làm màn hình nhập tệp có ghép cột, kiểm tra trước khi lưu và báo lỗi theo dòng, theo cột.
05Nhập thử một tệp thật, sửa lỗi dữ liệu cũ rồi mới nhập chính thức, có bản sao trước.

Bạn đưa vào

Bảng tính và danh sách hiện có
Tệp mẫu đã nhập gần nhất
Danh sách giá trị cố định, như vùng và trạng thái
Người chịu trách nhiệm từng loại dữ liệu

Bảng, quan hệ, quy tắc cộtONMATE cùng doanh nghiệp

Bạn nhận lại

Sơ đồ quan hệ, từ điển, quy tắc ở cơ sở dữ liệu, nhập tệp có kiểm tra, báo cáo chất lượng.

Tài liệu tham khảo:PostgreSQL: ràng buộc dữ liệu ↗OWASP: kiểm tra dữ liệu đầu vào ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để dựng dữ liệu.

Cần bảng tính thật đang dùng, kể cả bản lộn xộn nhất.

NGUYÊN TẮC

Từ điển ghi mỗi trường một dòng: kiểu, bắt buộc hay không, quy tắc, ví dụ. Màn hình, tệp nhập và API cùng đọc một từ điển.

TỪ ĐIỂN DỮ LIỆU · MẪU

docs.google.com/spreadsheets

nhathom-tu-dien-du-lieuTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Trường	Kiểu	Bắt buộc	Quy tắc	Ví dụ
2	dai_ly.ten	Chữ	Có	Tối đa 120 ký tự	Hương Sen
3	dai_ly.ma_so_thue	Chữ	Có	Duy nhất, 10 hoặc 13 số	0312345678
4	dai_ly.vung	Danh sách	Có	Một trong 6 vùng	Hồ Chí Minh
5	dai_ly.han_muc	Số	Có	Từ 0, đơn vị đồng	20000000
6	don_hang.trang_thai	Danh sách	Có	Một trong 6 trạng thái đã vẽ	cho_duyet

TrườngDanh sách giá trị

ma_so_thue: duy nhất, 10 hoặc 13 số. Từ điển ghi một lần, màn hình nhập, tệp nhập và API cùng dùng.
vung là danh sách đóng, 6 giá trị. Nhờ vậy báo cáo theo vùng không tách “HCM” và “Hồ Chí Minh” thành hai nhóm.
han_muc từ 0, đơn vị đồng: ghi rõ đơn vị. Số tiền thiếu đơn vị dễ lệch một nghìn lần khi đối chiếu.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Quy tắc ở cơ sở dữ liệu

Mọi đường vào kiểm như nhau

Danh sách đóng

Vùng, trạng thái chọn có sẵn

Ghi rõ đơn vị

Tiền, trọng lượng, số lượng

Kiểm tra trước khi nhập

Thấy lỗi trước khi lưu

Bộ tài nguyên4 mục

TệpBảng tính đang dùngDữ liệu thật, đã xóa chỗ nhạy cảm.
TệpTệp mẫu để nhập thửCSV đại diện, gồm cả dòng lộn xộn.
BảngDanh sách giá trị cố địnhVùng, loại đại lý, trạng thái đơn.
KháchNgười chịu trách nhiệm dữ liệuQuyết định khi hai nguồn ghi khác nhau.

Xem đủ thông số và ghi chú

Nguồn: Ràng buộc dữ liệu Tài liệu PostgreSQL mô tả các ràng buộc như bắt buộc, duy nhất, khóa ngoại và điều kiện kiểm tra, để cơ sở dữ liệu tự từ chối dữ liệu sai.
Nguồn: Tệp CSV và bảng mã RFC 4180 mô tả định dạng tệp CSV, còn W3C khuyên dùng UTF-8 cho nội dung web. Tệp lưu sai bảng mã làm chữ tiếng Việt bị vỡ.
Lưu ý: Đừng nhập thẳng vào dữ liệu thật Luôn có bước kiểm tra chưa lưu và bản sao trước khi nhập chính thức, vì gỡ dữ liệu nhập sai thường khó hơn nhập lại.

Tài liệu tham khảo:PostgreSQL: ràng buộc dữ liệu ↗W3C: chọn bảng mã ký tự ↗

ĐO ĐIỀU GÌ

Đo bằng chất lượng dữ liệu sau khi nhập.

Dữ liệu tốt thể hiện ở kết quả kiểm tra: bao nhiêu dòng hợp lệ, lỗi tập trung ở loại nào.

CẦN ĐO

Sửa loại lỗi nhiều nhất trước, rồi sửa quy tắc để lỗi không quay lại.

KẾT QUẢ KIỂM TRA DỮ LIỆU · SỐ MẪU

dulieu.nhathom.example/nhap/dai-ly/kiem-tra

DQuản trị dữ liệuCổng đại lý (mẫu)L

BảngQuan hệNhập tệpChất lượngCài đặt

Kết quả kiểm tra

dai-ly-thang-10.csv

Tổng quan

Tổng số dòng412Hợp lệ395Có lỗi17

Lỗi theo loại

Thiếu mã số thuế9
Trùng email5
Vùng ngoài danh sách3

Dòng lỗi

Dòng	Cột	Lỗi	Gợi ý
58	`ma_so_thue`	Để trống	Điền mã số thuế
131	`email`	Trùng với dòng 27	Giữ một dòng
307	`vung`	Không có trong danh sách	Chọn “Hồ Chí Minh”

Tổng quan: 412 dòng, 395 hợp lệ, 17 có lỗi. 395 cộng 17 bằng 412: không dòng nào bị bỏ lặng lẽ.
Lỗi theo loại: thiếu mã số thuế 9, trùng email 5, vùng ngoài danh sách 3. Sửa loại nhiều nhất trước.
Dòng 307: “Hồ Chi Minh” gõ thiếu dấu. Báo đúng dòng, đúng cột, gợi ý cách sửa, khỏi dò từng dòng.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Dòng hợp lệ	Chiếm gần hết tệp	Giảm đi ở lần nhập sau
Thiếu trường bắt buộc	Ít và có gợi ý sửa	Dồn vào một cột
Dòng trùng lặp	Được gộp hoặc giữ một dòng	Cùng một người xuất hiện nhiều lần
Giá trị ngoài danh sách	Có gợi ý giá trị đúng	Nhiều cách viết cho cùng một thứ

CÁCH ĐỌC

Mở kết quả kiểm tra của tệp, xem tổng số dòng hợp lệ và có lỗi, rồi đọc lỗi theo loại và từng dòng lỗi kèm gợi ý.

LƯU Ý

Hợp lệ chưa chắc đúng: mã số thuế đúng định dạng vẫn có thể gắn nhầm đại lý.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:OWASP: kiểm tra dữ liệu đầu vào ↗PostgreSQL: ràng buộc dữ liệu ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Dữ liệu đang nằm trong nhiều bảng tính

Gom và chuẩn hóa trước khi thiết kế bảng.

Thu thập các bảng tính
So sánh những cột giống nhau
Chọn nguồn đúng cho từng thứ
Thiết kế bảng và quan hệ

Đã có hệ thống nhưng dữ liệu bị lệch

Thêm quy tắc ở cơ sở dữ liệu rồi dọn dữ liệu cũ.

Chạy kiểm tra dữ liệu hiện có
Sửa hoặc gộp các dòng lỗi
Thêm ràng buộc
Báo cáo lại chất lượng

Cần nhập một danh sách lớn

Làm màn hình nhập có kiểm tra và thử bằng tệp nhỏ trước.

Nhập thử 20 dòng
Xem kết quả kiểm tra
Sửa tệp và cách ghép cột
Nhập chính thức sau khi sao lưu

DẤU HIỆU

Báo cáo theo vùng cộng sai

Chỉ số	Giá trị
Cách nhập vùng	Gõ tự do
Giá trị trong dữ liệu	HCM, Hồ Chí Minh, Hồ Chi Minh
Việc cần làm	Dùng danh sách 6 vùng và đổi dữ liệu cũ về đúng giá trị

KIỂM TRA

Vùng được gõ tự do nên một nơi có nhiều cách viết.

Đọc tiếp

Đổi thành danh sách đóng.

DẤU HIỆU

Hai đại lý mang cùng mã số thuế

Chỉ số	Giá trị
Nơi kiểm trùng	Chỉ ở màn hình nhập tay
Đường lọt qua	Nhập tệp và gọi API
Việc cần làm	Thêm ràng buộc duy nhất rồi gộp các dòng trùng cũ

KIỂM TRA

Chỉ kiểm trùng ở màn hình, không có ràng buộc duy nhất ở cơ sở dữ liệu.

Đọc tiếp

Thêm ràng buộc.

DẤU HIỆU

Chữ tiếng Việt bị vỡ sau khi nhập

Chỉ số	Giá trị
Bảng mã của tệp	Không phải UTF-8
Biểu hiện	Dấu bị thay bằng ký tự lạ
Việc cần làm	Lưu lại bằng UTF-8 và hiện bảng mã ở bước chọn tệp

KIỂM TRA

Tệp được lưu bằng bảng mã khác UTF-8.

Đọc tiếp

Lưu lại bằng UTF-8 và hiện bảng mã ở bước chọn tệp.

Tài liệu tham khảo:RFC 4180: định dạng tệp CSV ↗W3C: chọn bảng mã ký tự ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Có sơ đồ quan hệ ghi bảng, khóa chính, khóa ngoại và loại quan hệCó từ điển dữ liệu ghi kiểu, bắt buộc, quy tắc và ví dụ cho từng trườngQuy tắc nằm ở cơ sở dữ liệu, không chỉ ở màn hình nhậpCác giá trị cố định như vùng và trạng thái là danh sách đóngTiền, số lượng và đơn vị đo được ghi rõ đơn vịGiá trị có thể đổi theo thời gian, như đơn giá, được lưu lại tại lúc đặtNhập tệp có bước ghép cột, kiểm tra trước khi lưu và báo lỗi theo dòngCó bản sao dữ liệu trước mỗi lần nhập lớn và đã nhập thử một tệp thật

Tài liệu tham khảo:PostgreSQL: ràng buộc dữ liệu ↗OWASP: kiểm tra dữ liệu đầu vào ↗

Nội dung của thẻ Các hệ thống nối với nhauChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

API và kết nối trông như thế nào.

Ba màn hình: tài liệu một điểm cuối, thử gọi và nhật ký đồng bộ. Bấm từng mục để xem.

Tài liệu cho một điểm cuối

Trang ghi phương thức và đường dẫn, tham số, cách gửi khóa API và ví dụ phản hồi. Người làm bên kế toán đọc trang này là tự nối được.

Đọc tiếp

Ví dụ phản hồi nên được sinh từ chính hệ thống, không viết tay, để tên trường và kiểu dữ liệu luôn khớp.

MÔ PHỎNG · SỐ MẪU

daily.nhathom.example/tai-lieu-api/chi-tiet-don

ATài liệu APIPhiên bản v1L

Đơn hàngDanh sáchChi tiết đơnTạo đơnĐại lýSản phẩmMã lỗi

Chi tiết đơn

Chỉ đọc

GET/api/v1/orders/{id}

Trả về một đơn và các dòng sản phẩm. Chỉ đọc được đơn thuộc phạm vi của khóa API.

Tham số

Tên	Vị trí	Mô tả
`Authorization`	Header	Bearer và khóa API của hệ thống kế toán
`id`	Đường dẫn	Mã đơn, ví dụ DH-2051

Phản hồi 200application/json

{ "id": "DH-2051",
  "status": "cho_duyet",
  "total": 4200000,
  "lines": [ { "sku": "NT-GD-180", "qty": 24 } ] }3

Dòng đầu: phương thức GET và đường dẫn có biến {id}. GET chỉ đọc, không đổi dữ liệu nên gọi thử an toàn.
Authorization: mỗi lần gọi phải kèm khóa API. Khóa chỉ đọc được đơn trong phạm vi của nó, như quyền trên website.
Phản hồi 200: ví dụ thật gồm mã đơn, trạng thái, tổng tiền, dòng sản phẩm. Bên kế toán đọc là nối được.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Nhật ký đồng bộ kế toán, kho

Mỗi lượt gửi đơn sang kế toán hay kho có một dòng: giờ, đơn, nơi nhận, kết quả, lần thử. Lỗi 503 tự thử lại tối đa 3 lần.

Đọc tiếp

Sau 3 lần vẫn lỗi thì đơn chuyển vào hàng chờ xử lý tay có người nhận việc, nên đơn không bị mất.

MÔ PHỎNG · SỐ MẪU

daily.nhathom.example/quan-tri/tich-hop/dong-bo

NCổng đại lýQuản trịL

Đơn hàngĐại lýSản phẩmVai tròNhật kýTích hợpBáo cáo

Đồng bộ với phần mềm kế toán

24 giờ gần nhất

Tổng quan

Đã gửi312Thành công305Đang thử lại4Thất bại3

Lượt gần nhất

Giờ	Đơn	Nơi nhận	Kết quả	Lần thử
10:42	DH-2051	Kế toán	Thành công	1
10:40	DH-2050	Kế toán	Lỗi 503	2/3
10:31	DH-2049	Kế toán	Thành công	1
09:58	DH-2044	Kế toán	Thất bại	3/3
09:41	DH-2043	Kho	Thành công	1

Đơn thất bại sau 3 lần thử chuyển vào hàng chờ xử lý tay, không bị mất.

Tổng quan: 312 lượt gửi, 305 thành công, 4 đang thử lại, 3 thất bại. 305 cộng 4 cộng 3 bằng 312.
Lỗi 503, lần thử 2/3: phần mềm kế toán tạm bận. Hệ thống tự thử lại, phần lớn lỗi tạm thời tự hết.
Thất bại 3/3: ba lần thử vẫn lỗi nên vào hàng chờ xử lý tay. Người phụ trách nhận việc, không mất đơn.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:MDN: phương thức HTTP ↗OpenAPI: đặc tả mô tả API ↗

LÀM NHƯ THẾ NÀO

Năm bước nối hệ thống.

Hỏi bên kia trước. Mỗi điểm cuối có hợp đồng, mỗi hệ thống một khóa.

01Hỏi bên kế toán và kho: cần nhận gì, lúc nào, định dạng nào, hệ thống có cho nối không.
02Viết hợp đồng API: điểm cuối, phương thức, tham số, mã lỗi, giới hạn lượt gọi, ai được gọi.
03Cấp khóa API riêng cho từng hệ thống, vừa đủ quyền; dựng môi trường thử tách khỏi dữ liệu thật.
04Để bên nối thử trên môi trường thử, sửa tài liệu theo chỗ họ vướng rồi mới chạy thật.
05Theo dõi tỷ lệ thành công, lỗi 4xx, thời gian trả lời. Người xử lý tay việc trong hàng chờ.

Bạn đưa vào

Hệ thống cần nối, như kế toán và kho
Tài liệu API của hệ thống đó
Cách cấp khóa và quyền
Người của bên kia để hỏi khi có lỗi

Hợp đồng API, khóa, môi trường thửONMATE cùng doanh nghiệp

Bạn nhận lại

Tài liệu API, môi trường thử, khóa theo hệ thống, nhật ký đồng bộ, hàng chờ xử lý tay, báo cáo API.

Tài liệu tham khảo:OpenAPI: đặc tả mô tả API ↗OWASP: bảo mật REST ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để nối hệ thống.

Cần biết hệ thống bên kia cho nối bằng cách nào; cần người xác nhận sớm.

NGUYÊN TẮC

Hợp đồng API: mỗi dòng một điểm cuối, kèm đường dẫn, phương thức, ai gọi, giới hạn, lỗi. Hai bên đọc cùng bảng nên không phải đoán.

HỢP ĐỒNG API · MẪU

docs.google.com/spreadsheets

nhathom-hop-dong-apiTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Điểm cuối	Phương thức	Ai gọi	Giới hạn	Lỗi có thể gặp
2	/orders	GET	Kế toán, kho	60 lượt mỗi phút	401, 403, 429
3	/orders/{id}	GET	Kế toán, kho	60 lượt mỗi phút	401, 403, 404, 429
4	/orders	POST	Hệ thống của đại lý	20 lượt mỗi phút	400, 401, 409, 429
5	/dealers	GET	Kế toán	30 lượt mỗi phút	401, 403, 429
6	/stock	PUT	Kho	30 lượt mỗi phút	400, 401, 403, 409, 429

Điểm cuốiMã lỗi

POST /orders giới hạn 20 lượt mỗi phút. Ghi giới hạn thấp hơn đọc để lỗi lặp không tràn ngập đơn.
Mã 409: gửi trùng Idempotency-Key hoặc đơn vi phạm điều kiện. Biết trước lỗi, bên kế toán viết sẵn cách xử lý.
PUT /stock chỉ kho được gọi. Mỗi điểm cuối có đúng bên được gọi, khớp với bảng quyền theo vai trò.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Khóa riêng từng hệ thống

Thu hồi riêng từng khóa

Gửi lại không tạo trùng

Dùng Idempotency-Key

Có giới hạn lượt gọi

Lỗi lặp không làm tràn đơn

Mã lỗi rõ ràng

Bên nối biết xử lý mã

Bộ tài nguyên4 mục

TệpTài liệu API của bên kiaHoặc tên và phiên bản phần mềm.
KháchNgười liên hệ bên kiaNgười trả lời khi lỗi ở phía họ.
BảngDữ liệu cần trao đổiGửi gì, chiều nào, bao lâu một lần.
KháchMôi trường thử của bên kiaThử không động tới dữ liệu thật.

Xem đủ thông số và ghi chú

Nguồn: Phương thức HTTP MDN mô tả GET là chỉ đọc còn POST dùng để tạo hoặc gửi dữ liệu. Chọn đúng phương thức để gọi thử không làm hỏng dữ liệu.
Nguồn: Gửi lại an toàn MDN giải thích thao tác idempotent là thao tác gọi nhiều lần cho cùng kết quả như gọi một lần. Với thao tác tạo mới, nhiều hệ thống thêm khóa Idempotency-Key để gửi lại không tạo trùng.
Lưu ý: Đừng đưa khóa API vào địa chỉ hay mã nguồn OWASP khuyên lưu khóa và bí mật ở nơi quản lý riêng và đổi định kỳ, không đưa vào mã nguồn hay đường dẫn.

Tài liệu tham khảo:MDN: phương thức HTTP ↗MDN: idempotent ↗

ĐO ĐIỀU GÌ

Đo bằng sức khỏe API.

API khỏe thể hiện ở tỷ lệ thành công, lượt bị từ chối và thời gian trả lời. Theo dõi hằng ngày.

CẦN ĐO

Đọc p95 thay vì trung bình, và đọc mã lỗi theo từng loại.

SỨC KHỎE API · SỐ MẪU

daily.nhathom.example/quan-tri/tich-hop/api

NCổng đại lýQuản trịL

Đơn hàngĐại lýSản phẩmVai tròNhật kýTích hợpBáo cáo

Sức khỏe API

24 giờ gần nhất

Tổng quan

Lượt gọi12.480Thành công99,5%Bị từ chối (4xx)65Trả lời TB184 ms

Theo mã trạng thái

200 OK12.352
201 Tạo mới63
401 Sai khóa22
403 Không có quyền37
429 Quá nhiều lượt6

Điểm cuối

Điểm cuối	Lượt	TB	p95
`GET /orders`	8.246	142 ms	310 ms
`GET /orders/{id}`	3.571	96 ms	180 ms
`POST /orders`	63	402 ms	780 ms
Còn lại	600	88 ms	170 ms

Thành công 99,5%: 12.415 trên 12.480 lượt. Theo dõi con số này hằng ngày, tụt là biết có chuyện trước khi khách báo.
401 và 403: 22 và 37 lượt bị từ chối vì sai khóa hoặc thiếu quyền. Tăng đột ngột là dấu hiệu bất thường.
POST /orders p95 780 ms: ghi chậm hơn đọc là bình thường. Theo dõi p95: người dùng nhớ lần chậm nhất.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Tỷ lệ thành công	Gần như toàn bộ lượt gọi	Tụt đột ngột trong ngày
401 và 403	Vài chục lượt mỗi ngày	Tăng vọt hoặc dồn vào một khóa
429 quá nhiều lượt	Hiếm	Lặp lại ở cùng một hệ thống
p95 của điểm cuối ghi dữ liệu	Ổn định	Tăng dần qua các tuần

CÁCH ĐỌC

Mở Sức khỏe API, đọc bốn con số đầu và bảng theo mã trạng thái, rồi đọc bảng điểm cuối với cột TB và p95.

LƯU Ý

Thành công cao chưa nói dữ liệu đúng: một lượt gọi vẫn có thể gửi sai nội dung.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:MDN: mã 429 Too Many Requests ↗OWASP: ghi nhật ký ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Cần nối với phần mềm kế toán

Xác nhận cách nối trước rồi mới viết hợp đồng.

Hỏi phần mềm có API không
Viết hợp đồng API
Nối thử trên môi trường thử
Chạy thật và theo dõi

Đại lý lớn muốn gửi đơn từ hệ thống riêng

Cấp khóa riêng và dựng tài liệu để họ tự nối.

Viết tài liệu điểm cuối tạo đơn
Cấp khóa và giới hạn lượt gọi
Cho họ thử ở môi trường thử
Theo dõi lượt gọi của khóa đó

Đồng bộ hay lỗi mà chưa rõ vì sao

Bắt đầu từ nhật ký đồng bộ rồi phân loại lỗi.

Xem nhật ký đồng bộ
Phân loại lỗi theo mã
Thêm thử lại cho lỗi tạm thời
Có người nhận việc từ hàng chờ

DẤU HIỆU

Đơn bị tạo hai lần khi mạng đứt

Chỉ số	Giá trị
Khóa chống trùng	Chưa có
Biểu hiện	Cùng một đơn xuất hiện hai lần
Việc cần làm	Gửi kèm Idempotency-Key, gửi lại cùng khóa thì trả kết quả cũ

KIỂM TRA

Hệ thống gửi lại mà không có khóa chống trùng.

Đọc tiếp

Thêm Idempotency-Key cho thao tác tạo.

DẤU HIỆU

Đơn chưa sang kế toán mà không ai biết

Chỉ số	Giá trị
Sau lỗi 503	Bỏ qua
Số đơn thất bại	3 trong 24 giờ
Việc cần làm	Thử lại tối đa 3 lần rồi chuyển vào hàng chờ có người nhận

KIỂM TRA

Lỗi tạm thời không được thử lại và không có hàng chờ.

Đọc tiếp

Thêm thử lại và hàng chờ xử lý tay.

DẤU HIỆU

Khóa API nằm trong tệp mã nguồn

Chỉ số	Giá trị
Nơi lưu khóa	Trong tệp mã nguồn
Rủi ro	Ai thấy tệp đều gọi được API
Việc cần làm	Thu hồi, cấp khóa mới và lưu ở nơi quản lý riêng

KIỂM TRA

Khóa bị chép vào mã nguồn hoặc đường dẫn nên ai thấy tệp cũng gọi được.

Đọc tiếp

Thu hồi và cấp khóa mới.

Tài liệu tham khảo:MDN: mã trạng thái HTTP ↗OWASP: quản lý khóa và bí mật ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Có tài liệu API cho từng điểm cuối: phương thức, đường dẫn, tham số, phản hồi và mã lỗiCó môi trường thử tách khỏi dữ liệu thật và ghi rõ trên màn hìnhMỗi hệ thống có khóa API riêng với phạm vi vừa đủ, khóa không nằm trong mã nguồn hay địa chỉThao tác tạo mới hỗ trợ gửi lại an toàn bằng Idempotency-KeyCó giới hạn lượt gọi và mã 429 được ghi trong tài liệuLỗi tạm thời được thử lại tự động, lỗi còn lại vào hàng chờ có người nhậnCó nhật ký đồng bộ ghi giờ, đơn, nơi nhận, kết quả và lần thửCó theo dõi tỷ lệ thành công, lỗi 4xx và p95 hằng ngày

Tài liệu tham khảo:OWASP: API Security Top 10 ↗RFC 9110: ngữ nghĩa HTTP ↗

Nội dung của thẻ Tìm lỗi trước người dùng thậtChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Kiểm thử và nghiệm thu trông như thế nào.

Ba màn hình: ca kiểm thử, lần chạy tự động và biên bản nghiệm thu. Bấm từng mục để xem.

Ca kiểm thử nối về yêu cầu

Mỗi ca ghi mã, tên, câu chuyện CDL được kiểm và kết quả. Phần đầu cho biết đợt 1 có 86 ca: 71 đạt, 6 không đạt, 9 chưa chạy.

Đọc tiếp

Ca không nối được về câu chuyện nào là ca thừa hoặc dấu hiệu yêu cầu còn thiếu. Cả hai đều cần hỏi lại.

MÔ PHỎNG · SỐ MẪU

quanly.nhathom.example/kiem-thu/ca

QQuản lý yêu cầuCổng đại lý (mẫu)L

Yêu cầuBảng đợtBáo cáoThành viênCài đặt

Ca kiểm thử

Đợt 1 · 86 ca

Tổng quan

Tổng số ca86Đạt71Không đạt6Chưa chạy9

Ca gần đây

Mã	Ca kiểm thử	Yêu cầu	Kết quả
TC-014	Đại lý đặt lại đơn cũ	CDL-102	Đạt
TC-015	Sản phẩm ngừng bán bị bỏ khỏi giỏ	CDL-102	Đạt
TC-031	Đại lý xem đơn của đại lý khác	CDL-110	Đạt
TC-052	Duyệt đơn vượt hạn mức	CDL-103	Không đạt
TC-066	Nhập tệp có dòng lỗi	CDL-130	Chưa chạy

Tổng quan: 86 ca, 71 đạt, 6 không đạt, 9 chưa chạy. Cộng lại bằng 86: ca chưa chạy cũng được đếm.
Cột Yêu cầu: mỗi ca nối về một câu chuyện CDL, không có ca mồ côi. Bấm vào thấy điều kiện được kiểm.
TC-052 không đạt: duyệt đơn vượt hạn mức mà hệ thống vẫn cho duyệt. Lỗi thật, ghi lại và chuyển sang bảng lỗi.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Người dùng thật thử từng chức năng

Mỗi chức năng có người xem, ngày xem và kết quả Được duyệt hoặc Cần sửa. Ý kiến ghi ngay bên cạnh để thành điều kiện hoặc lỗi.

Đọc tiếp

Người nghiệm thu nên là người sẽ dùng hệ thống hằng ngày, không phải người đã viết đặc tả. Họ thấy những chỗ mà bản vẽ không cho thấy được.

MÔ PHỎNG · SỐ MẪU

quanly.nhathom.example/nghiem-thu/dot-1

QQuản lý yêu cầuCổng đại lý (mẫu)L

Yêu cầuBảng đợtBáo cáoThành viênCài đặt

Nghiệm thu đợt 1

30 chức năng đã làm

Tổng quan

Đã làm30Được duyệt26Cần sửa4

Người dùng thật xem từng chức năng

Chức năng	Người xem	Ngày	Kết quả
Đặt đơn từ danh mục	Hà Trang	04/10	Được duyệt
Đặt lại đơn cũ	Hà Trang	04/10	Được duyệt
Duyệt đơn trong vùng	Minh Tuấn	05/10	Cần sửa
Soạn và giao hàng	Thanh Bình	06/10	Được duyệt

Minh Tuấn05/10/2026 · Duyệt đơn trong vùng

Khi từ chối đơn cần bắt buộc ghi lý do, để đại lý biết phải sửa gì.

Tổng quan: 30 chức năng đã làm, 26 được duyệt, 4 cần sửa. Cộng lại bằng 30, không chức năng nào lửng lơ.
Cần sửa: người dùng thật xem Duyệt đơn trong vùng và chưa chấp nhận. Mỗi chức năng có tên người xem và ngày xem.
Ý kiến người xem nói rõ cần gì (“bắt buộc ghi lý do”), nên thành ngay điều kiện chấp nhận mới.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:Martin Fowler: kim tự tháp kiểm thử ↗Atlassian: điều kiện chấp nhận ↗

LÀM NHƯ THẾ NÀO

Năm bước kiểm thử.

Xuất phát từ điều kiện chấp nhận. Máy chạy lặp, người thật thử phần còn lại.

01Viết ca từ điều kiện: dữ liệu vào, thao tác, kết quả mong đợi, nối về một câu chuyện.
02Viết ca cho cả đường đi đúng, đường đi sai và truy cập trái quyền.
03Cho máy tự chạy các ca sau mỗi thay đổi. Ca lỗi chặn việc đưa lên bản thử.
04Đưa bản thử cho người dùng thật, mỗi người một chức năng. Ý kiến ghi thành điều kiện hoặc lỗi.
05Lỗi theo dõi trên một bảng, đóng khi người báo xác nhận; phát hành khi ca quan trọng đã qua.

Bạn đưa vào

Điều kiện chấp nhận đã duyệt
Dữ liệu mẫu để kiểm thử
Người dùng thật sẽ nghiệm thu
Ngày dự kiến phát hành

Ca kiểm thử, chạy tự động, nghiệm thuONMATE cùng doanh nghiệp

Bạn nhận lại

Bộ ca kiểm thử nối về yêu cầu, lần chạy tự động, biên bản nghiệm thu từng chức năng, bảng lỗi.

Tài liệu tham khảo:Martin Fowler: tích hợp liên tục ↗Martin Fowler: kim tự tháp kiểm thử ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để kiểm thử.

Cần điều kiện chấp nhận đã duyệt và người thật để nghiệm thu.

NGUYÊN TẮC

Kế hoạch chia ca theo nhóm chức năng: số ca, đạt, không đạt, chưa chạy, người phụ trách. Nhóm phân quyền chạy đầu và phải đạt hết.

KẾ HOẠCH KIỂM THỬ · MẪU

docs.google.com/spreadsheets

nhathom-ke-hoach-kiem-thuTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E	F
1	Nhóm	Số ca	Đạt	Không đạt	Chưa chạy	Phụ trách
2	Đặt hàng	22	20	1	1	Hà Trang
3	Duyệt đơn	18	14	3	1	Minh Tuấn
4	Kho và giao hàng	16	13	1	2	Thanh Bình
5	Phân quyền	14	14	0	0	Lan Anh
6	Nhập tệp	10	6	1	3	Hà Trang
7	Hóa đơn	6	4	0	2	Lan Anh
8	Tổng cộng	86	71	6	9	—

Theo nhómChưa chạy

Duyệt đơn có 3 ca không đạt: nhóm nhiều lỗi nhất. Xem theo nhóm để biết cần sửa gì trước khi nghiệm thu.
Phân quyền 14 trên 14 đạt: nhóm quan trọng nhất về bảo mật, gồm cả ca đại lý mở đơn người khác.
Nhập tệp còn 3 ca chưa chạy: chờ tệp mẫu từ kế toán. Ca chưa chạy ghi riêng, không lẫn vào ca đạt.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Mỗi ca nối về yêu cầu

Không có ca mồ côi

Có ca trái quyền

Thử mở dữ liệu người khác

Máy tự chạy lại

Sau mỗi thay đổi

Người dùng thật nghiệm thu

Không chỉ người làm tự xem

Bộ tài nguyên4 mục

KháchNgười nghiệm thuMỗi vai trò một người dùng thật.
TệpDữ liệu mẫuĐại lý, sản phẩm, đơn mẫu, không thật.
BảngTrường hợp từng saiĐơn tính sai, giao nhầm thành ca riêng.
KháchĐiều kiện phát hànhCa phải đạt, mức lỗi được tồn.

Xem đủ thông số và ghi chú

Nguồn: Kim tự tháp kiểm thử Martin Fowler gợi ý nhiều ca nhỏ chạy nhanh ở tầng dưới và ít ca đi qua giao diện ở tầng trên, để kiểm được nhiều mà vẫn chạy nhanh.
Nguồn: Tích hợp liên tục Martin Fowler mô tả việc gộp thay đổi thường xuyên và để máy dựng, kiểm tra ở mỗi lần gộp, nhờ đó lỗi được phát hiện sớm khi còn nhỏ.
Lưu ý: Kiểm thử bảo mật là một phần Hướng dẫn kiểm thử bảo mật web của OWASP có danh sách ca kiểm tra phân quyền, quản lý phiên và dữ liệu vào. Nên có ít nhất các ca truy cập trái quyền.

Tài liệu tham khảo:Martin Fowler: kim tự tháp kiểm thử ↗OWASP: hướng dẫn kiểm thử bảo mật web ↗

ĐO ĐIỀU GÌ

Đo bằng bảng lỗi.

Bảng lỗi cho biết lỗi nào đang mở, mức nào, chờ ai. Số lỗi mở giảm đều qua các đợt là tốt.

CẦN ĐO

Lỗi mức Cao nằm ở cột Mới quá lâu là chỗ cần hỏi.

BẢNG LỖI · SỐ MẪU

quanly.nhathom.example/loi

QQuản lý yêu cầuCổng đại lý (mẫu)L

Yêu cầuBảng đợtBáo cáoThành viênCài đặt

Bảng lỗi

6 lỗi đang mở

Mới2

Lý do từ chối không hiện cho đại lý

BUG-041Cao

Ngày giao lệch một ngày ở Safari

BUG-042Thấp

Đang sửa2

Tồn kho âm khi hai người soạn cùng lúc

BUG-037Cao

Xuất hóa đơn chậm khi đơn trên 50 dòng

BUG-039Vừa

Chờ kiểm lại2

Đặt lại đơn bỏ sót sản phẩm mới

BUG-033Vừa

Sai chính tả nút Từ chối

BUG-035Thấp

Cột Mới: 2 lỗi chưa ai nhận. Mỗi lỗi có mã, tên ngắn và mức độ để xếp thứ tự xử lý.
Đang sửa: 2 lỗi, gồm BUG-037 tồn kho âm khi hai người soạn cùng lúc, mức Cao. Lỗi số liệu kho làm trước.
Chờ kiểm lại: đã sửa nhưng người báo lỗi chưa xác nhận. Lỗi chỉ đóng khi người báo thấy hết lỗi.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Lỗi mức Cao đang mở	Không còn khi phát hành	Nằm ở cột Mới nhiều ngày
Lỗi ở cột Đang sửa	Ít và có người nhận	Một người phụ trách nhiều lỗi
Lỗi chờ kiểm lại	Người báo xác nhận trong vài ngày	Nằm lâu vì người báo chưa xem
Lỗi lặp lại	Hiếm	Cùng một chức năng nhiều lần

CÁCH ĐỌC

Mở Bảng lỗi, nhìn số lỗi ở từng cột rồi đọc mức độ của từng thẻ.

Đọc tiếp

Mở các lỗi mức Cao trước.

LƯU Ý

Ít lỗi có thể do chưa kiểm hết.

Đọc tiếp

Đọc cùng số ca chưa chạy. Số trong hình là số mẫu.

Tài liệu tham khảo:Martin Fowler: tích hợp liên tục ↗Scrum Guide: định nghĩa hoàn thành ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Dự án mới có đặc tả đã duyệt

Viết ca kiểm thử song song với việc làm, không chờ làm xong.

Chuyển điều kiện thành ca
Viết ca đường sai và trái quyền
Cho máy tự chạy
Nghiệm thu theo đợt

Hệ thống đang chạy và hay hỏng khi sửa

Thêm ca kiểm thử cho phần hay hỏng trước rồi mở rộng dần.

Liệt kê chỗ hay hỏng
Viết ca cho các chỗ đó
Cho máy tự chạy
Thêm ca sau mỗi lỗi mới

Sắp phát hành mà chưa nghiệm thu

Xếp ca theo mức quan trọng và chạy các ca quan trọng trước.

Chọn ca bắt buộc phải đạt
Chạy phân quyền, đơn hàng, tiền
Cho người dùng thật thử
Quyết định phát hành hay lùi lại

DẤU HIỆU

Sửa chỗ này hỏng chỗ khác

Chỉ số	Giá trị
Ca chạy tự động	Chưa có
Cách phát hiện lỗi	Khi người dùng báo
Việc cần làm	Viết ca cho phần hay vỡ và chạy sau mỗi thay đổi

KIỂM TRA

Chưa có ca kiểm thử tự chạy nên không ai biết ngay.

Đọc tiếp

Thêm ca cho phần dễ vỡ và cho máy chạy sau mỗi thay đổi.

DẤU HIỆU

Nghiệm thu xong rồi vẫn bị phàn nàn

Chỉ số	Giá trị
Người nghiệm thu	Người viết đặc tả
Người dùng thật	Chưa được thử
Việc cần làm	Mỗi vai trò có người thử chức năng của mình

KIỂM TRA

Người xem thử không phải người dùng hằng ngày.

Đọc tiếp

Cho người của từng vai trò thử đúng chức năng của họ.

DẤU HIỆU

Lỗi được báo rồi bị quên

Chỉ số	Giá trị
Nơi ghi lỗi	Tin nhắn riêng lẻ
Lỗi chưa có người nhận	Không ai đếm
Việc cần làm	Ghi mọi lỗi vào một bảng, mỗi lỗi có người nhận và mức độ

KIỂM TRA

Lỗi không có chỗ theo dõi nên không ai nhận.

Đọc tiếp

Dùng một bảng lỗi có người nhận và mức độ.

Tài liệu tham khảo:Martin Fowler: tích hợp liên tục ↗OWASP: hướng dẫn kiểm thử bảo mật web ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Mỗi điều kiện chấp nhận có ít nhất một ca kiểm thử nối về câu chuyệnCó ca cho đường đi sai và các ca truy cập trái quyềnCác ca chạy tự động sau mỗi thay đổi, ca lỗi chặn việc đưa lên bản thửKế hoạch kiểm thử đếm cả ca chưa chạy và số liệu cộng khớpCó môi trường thử với dữ liệu mẫu, không dùng thông tin thật của khách hàngMỗi vai trò có người dùng thật nghiệm thu chức năng của mình, ghi tên và ngàyMọi lỗi nằm trên một bảng, có mức độ và người nhận, chỉ đóng khi người báo xác nhậnCó điều kiện phát hành bằng văn bản: ca nào phải đạt và mức lỗi nào được còn tồn

Tài liệu tham khảo:OWASP: hướng dẫn kiểm thử bảo mật web ↗Scrum Guide: định nghĩa hoàn thành ↗

NHỚ NHANH

Sáu phần việc, từ yêu cầu viết ra giấy đến người dùng nghiệm thu.

Chọn một ô để quay lại đúng phần nội dung ở trên.

CÓ THỂ CẦN THÊM

Dịch vụ website đi cùng.

01Tích hợp hệ thốngForm, CRM, API và dữ liệu.02UI/UXLuồng thao tác và bản mẫu có trạng thái.03Bảo trì WebsiteSao lưu, cập nhật, xử lý sự cố.

Website theo yêu cầu

Website theo yêu cầu tốt bắt đầu từ việc làm rõ nghiệp vụ, rồi mới chọn công nghệ.

Làm rõ yêu cầu

Phân quyền

Vẽ luồng nghiệp vụ

Dựng dữ liệu

Nối hệ thống

Kiểm thử và nghiệm thu

Chọn một phần việc để xem toàn bộ cách làm.

Yêu cầu rõ, nghiệm thu dễ — Mỗi chức năng viết kèm điều kiện thử được; việc ngoài phạm vi ghi rõ.

Yêu cầu và phạm vi trông như thế nào.

Danh sách theo đợt và ưu tiên

Yêu cầu

Câu chuyện có điều kiện thử được

CDL-102 · Đặt lại đơn cũ

Tài liệu có phiên bản, người duyệt

Phạm vi dự án

Trong phạm vi: 42 câu chuyện, ba đợt1

Ngoài phạm vi: 9 việc, để đợt sau2

Giả định cần xác nhận3

Năm bước viết yêu cầu.

Cần chuẩn bị gì để viết yêu cầu.

Mỗi dòng một câu chuyện

Điều kiện kiểm được

Ghi cả ngoài phạm vi

Có người duyệt

Đo bằng số thay đổi sau khi chốt.

Báo cáo yêu cầu

Cách xử lý các tình huống thường gặp.

Quy trình đang chạy bằng bảng tính và tin nhắn

Đã có đặc tả nhưng thiếu điều kiện chấp nhận

Dự án đang bị phát sinh liên tục

Danh sách kiểm tra.

Mỗi người đúng phần của mình — Vai trò xem và làm được gì; máy chủ kiểm từng yêu cầu, ghi nhật ký.

Vai trò và phân quyền trông như thế nào.

Năm vai trò, mỗi vai một phạm vi

Vai trò

Ma trận quyền một trang

Quyền theo vai trò

Khi không có quyền, người dùng thấy gì

Đơn hàng DH-2048

Năm bước phân quyền.

Cần chuẩn bị gì để phân quyền.

Quyền tối thiểu

Kiểm ở máy chủ

Giới hạn theo bản ghi

Có nhật ký

Đo bằng nhật ký truy cập.

Nhật ký truy cập

Cách xử lý các tình huống thường gặp.

Hệ thống mới có nhiều vai trò

Hệ thống đang dùng chung một tài khoản

Nghi có người xem dữ liệu không thuộc phần mình

Danh sách kiểm tra.

Vẽ luồng trước khi viết mã — Sơ đồ ai làm gì, vòng đời đơn và bản mẫu bấm được để thử trước.

Luồng nghiệp vụ trông như thế nào.

Ai làm bước nào, theo thứ tự

Từ đặt đơn tới thanh toán

Vòng đời của một đơn hàng

Vòng đời của một đơn hàng

Bản mẫu bấm được trước khi viết mã

Bản mẫu: gửi đơn

Năm bước vẽ luồng.

Cần chuẩn bị gì để vẽ luồng.

Một điểm kết thúc

Mỗi lần chuyển có người làm

Có nhánh từ chối

Thử trên bản mẫu

Đo bằng thời gian xử lý của đơn.

Thời gian xử lý đơn

Cách xử lý các tình huống thường gặp.

Quy trình chưa từng được vẽ ra

Có sơ đồ nhưng hay bị bỏ qua

Đơn hay bị kẹt mà không rõ ở đâu

Danh sách kiểm tra.

Dữ liệu sạch từ lúc nhập — Sơ đồ quan hệ, quy tắc từng cột và bước kiểm tra trước khi nhập tệp.

Dữ liệu và nhập tệp trông như thế nào.

Bảng nào nối với bảng nào

Sơ đồ quan hệ

Quy tắc của từng cột

Chọn một phần việc để xem
toàn bộ cách làm.

Trong phạm vi: 42 câu chuyện, ba đợt

Ngoài phạm vi: 9 việc, để đợt sau

Giả định cần xác nhận