Quy trình 1, Bán sản phẩm và đặt hàng

Nhóm bán hàng tạo đơn hàng bán hàng là kết quả của việc nhận được đơn đặt hàng của
khách hàng (qua đường bưu điện hai lần mỗi ngày), đơn đặt hàng do nhóm bán hàng lưu
động chuyển đến và các cuộc gọi bán hàng được nhận hoặc thực hiện trong suốt cả ngày. Khi
nhận được đơn đặt hàng, chúng sẽ được ghi lại trên (các / tờ) bảng tính bán hàng chính của
nhóm bán hàng, được sử dụng để in ra đơn hàng bán nhiều phần.
Đơn đặt hàng bán nhiều phần bao gồm:
● Đơn đặt hàng (được nhập trong hồ sơ tổng thể về khách hàng, cùng với đơn đặt hàng
của khách hàng nếu đã nhận được)
● Phiếu xuất hàng(gửi theo lô và chuyển đến kho hàng bốn lần một ngày để lấy và đóng
gói)
● Một phiếu giao hàng (kèm theo phiếu gửi và được đính kèm với bưu kiện, sau đó được
chuyển cho người chuyển phát nhanh để giao cho khách hàng)
Vào đầu ngày, bộ phận kho chuyển phiếu trả hàng của ngày hôm trước và nhân viên nhóm
bán hàng cập nhật thông tin bán hàng với thông tin trước khi nộp chúng vào tệp khách hàng
tổng thể. Bộ phận kho cũng chuyển danh sách các sản phẩm tồn kho ở mức thấp báo
động và những sản phẩm đã được chuyển vào kho ngày hôm trước. Đối với các đơn đặt hàng
không thể được lấp đầy hoàn toàn, các phiếu xuất hàng cũng được chuyển lại để nhóm bán
hàng có thể thông báo cho khách hàng và ưu tiên lấp đầy chúng khi hàng mới về.
Vào đầu ngày, bộ phận Kế toán gửi danh sách các khách hàng sắp hết hạn mức tín
dụng của họ. Nhân viên nhóm bán hàng kiểm tra hạn mức điều này khi họ tạo đơn đặt hàng
để đảm bảo rằng mỗi khách hàng vẫn nằm trong giới hạn của họ.
Vào cuối ngày, trưởng nhóm bán hàng lập báo cáo bán hàng và trả hàng được chuyển cho bộ
phận Kế toán. Nó chứa thông tin về các đơn đặt hàng bán hàng cho ngày hôm đó và chi tiết về
doanh thu của ngày hôm qua.Nó bao gồm giá trị đơn đặt hàng / trả lại, có tính đến bất kỳ lợi
nhuận nào không phù hợp với hàng tồn kho.
Hàng tháng, hoặc sớm hơn nếu được yêu cầu, trưởng nhóm bán hàng chuẩn bị báo cáo bán
hàng từ sheet bán hàng tổng thể cho bộ phận tiếp thị. Báo cáo bán hàng bao gồm:
● Bản tóm tắt về di chuyển hàng tồn kho tốt nhất và kém nhất
● trên cơ sở khách hàng, giá trị và các sản phẩm đã mua.
Hàng tháng, hoặc đôi khi thường xuyên hơn, trưởng nhóm bán hàng sẽ gửi email cho tất cả
khách hàng với một lưu ý thân thiện và chi tiết về bất kỳ ưu đãi nào, v.v. Mục đích chính là
chuyển hàng tồn kho chậm hoặc ngừng cung cấp.
Mọi khách hàng mới đều được bộ phận Kế toán kiểm tra tín dụng trước khi được phép đặt
hàng. Nếu họ vừa đăng kí TK vừa đặt hàng, đơn đặt hàng sẽ được giữ lại cho đến khi các tài
khoản hoàn tất việc kiểm tra. Sau khi hoàn tất, bộ phận kế toán sẽ chuyển thông tin chi tiết và
hạn mức tín dụng của khách hàng cho các hoạt động bán hàng (các tài khoản sẽ tạo một tệp
mới trong tệp chính của khách hàng), cùng với đơn đặt hàng nếu được bao gồm trong đơn
đăng ký của họ. Ngoại lệ chính - nếu bị từ chối, bộ phận bán hàng sẽ gọi cho khách hàng để
giải thích.

N.o Vấn đề Mô tả Giải pháp

1 Khách đặt hàng qua Cách thức nhận đơn đặt Song song với việc giữ các
đường bưu điện,nhóm hàng truyền thống này phương thức đặt hàng hiện tại
 bán hàng lưu động hoặc sẽ gây tốn nhiều thời (gọi điện, bưu điện, đội bán
gọi điện đặt hàng gian của cả khách hàng hàng lưu động để giữ lượng
và bộ phận bán hàng khách hàng đã quen với các
trong việc cung cấp phương thức này) thì cần thiết
thông tin đồng thời có lập một hệ thống bán hàng mới
thể nhầm lẫn trong quá
hiệu quả hơn như các trang
trình ghi chép/nhận
thông tin đặt hàng thương mại điện tử để có thể
hỗ trợ đặt hàng nhanh chóng,
dễ dàng. Đồng thời khi sử dụng
trang bán hàng thương mại
điện tử, mỗi đơn đặt hàng đều
được hệ thống ghi lại cả thông
tin khách hàng và thông tin đơn
hàng, khách hàng sẽ kiểm tra
lại thông tin trước khi chọn đặt
hàng. Thông tin này sẽ chuyển
đến bộ phận bán hàng để sử
dụng trực tiếp thông tin mà
không cần nhập thủ công thông
tin đơn hàng như cách đặt hàng
truyền thống.
VD: Shopee, Lazada, Tiki,...

Bộ phận kho chuyển Bộ phận kho nhận lại
phiếu trả hàng các đơn hàng trả lại từ
khách hàng sau đó gửi
lại các phiếu trả hàng có
thể dẫn đến việc thất lạc
các phiếu trả hàng hoặc
có thể dẫn tới các vấn
đề trong việc cập
nhật,duy trì lượng hàng
tồn kho
2
VD: Tham khảo phần mềm
POS365
Cần hệ thống cho phép cập
nhật tình trạng trả hàng
thay cho phiếu trả hàng để
phòng kho và nhóm bán
hàng dễ dàng cùng theo
dõi giúp quá trình xử lý đơn
hàng được rút ngắn, tránh
được sai sót trong đơn
hàng. Khi khách hàng có
yêu cầu trả hàng, họ chỉ
cần điền đầy đủ thông tin
khách hàng, chi tiết đơn
hàng lên hệ thống và lý do
muốn trả hàng; nhờ đó bên
quản lý kho có thể xử lý
nhanh đơn hàng đồng thời
nhóm bán hàng cũng
nhanh chóng cập nhật
được thông tin bán hàng
tổng hợp.
 

3 Bộ phận kho cũng Vào đầu ngày bộ phận Cần có hệ thống lưu trữ
chuyển danh sách các kho mới chuyển danh thông tin đặt hàng của
sản phẩm tồn kho ở mức sách hàng tồn kho ở khách (bao gồm hạn mức
thấp báo động mức thấp, điều này có tín dụng) để bộ phận kế
 thể ảnh hưởng tới việc toán kiểm tra và bộ phận
đặt hàng, trong trường bán hàng có thể cập nhật,
hợp các mặt hàng trong theo dõi và kiểm tra trực
ngày hôm nay chưa ở tiếp để xác nhận đơn hàng
mức báo động, ví dụ nếu phù hợp. tiết kiệm thời
mức báo động là 50, gian tổng hợp báo cáo và
trong kho vẫn còn 100 gửi đi.
(chưa ở mức báo động) VD: sử dụng phần mềm KiotViet,
tuy vậy hôm nay số Sapo GO, Haravan,...
lượng đơn hàng cho mặt
hàng là trên 100.Điều
này khiến cho bên bộ
phận bán hàng không
thể chủ động nắm số
lượng, và khi nhận đơn
đặt hàng nhưng ngày
hôm sau mới nhận lại
phiếu xuất hàng (vì hàng
không đủ và phải liên hệ
khách hàng để thông
báo)

Vào đầu ngày bộ phận Khi tạo đơn đặt hàng

kế toán gửi danh sách cho khách hàng, bộ
khách hàng sắp hết hạn phận bán hàng sẽ kiểm
mức tra hạn mức tín dụng
của tất cả khách hàng
nên việc gửi danh sách
khách hàng có hạn mức
4 tín dụng thấp là không
cần thiết, việc này bộ
phận bán hàng có thể
chủ động hơn, để dễ
dàng hơn có thể có các
công cụ hỗ trợ lọc ra các
khách hàng có mức tín
dụng thấp

+ Select 1 core solution and make below tasks:

- Draw Business Process Model (BPMN) of new business processes with detail description.

Vấn đề 1: Khách đặt hàng qua đường bưu điện,nhóm bán hàng lưu động hoặc gọi điện
đặt hàng

1. Quy trình tổng quát cũ

2. Quy trình tổng quát mới

3. Quy trình đặt hàng mới (cắt từ quy trình tổng quát mới)
- Make Use Case diagram and select 2 core Use Case to make detail Specification:

+ Make Use Case diagram:

1. Lý thuyết

Use Case là kỹ thuật mô tả sự tương tác giữa người dùng và hệ thống (trong 1 môi trường cụ thể,
vì 1 mục đích cụ thể).

Sự tương tác này có thể là:

Cách thức mà người dùng tương tác với hệ thống;

Cách thức mà hệ thống tương tác với các hệ thống khác.

Về hình thức thì Use Case tồn tại ở 2 dạng:

Hình vẽ Use Case (Use Case Diagram)

Đặc tả Use Case (Use Case Specification).

Use Case Diagram gồm 5 thành phần chính:

Actor

Use Case

Communication Link
 Boundary of System

Relationships.

2. Use Case diagram Vđ1:

 Use Case Specification
1. Use Case Specification là gì ?
Ta thấy rằng Use Case Diagram khá là chung chung để các stakeholders có cái nhìn trực
quan về những requirements được mô tả.
Do đó mà ta phải diễn đạt nó một cách chi tiết hơn và Use Case Specification sẽ giúp
chúng ta làm việc đó.
2. Các thành phần có trong Use Case Specification
● Summary
● Flow
● Additional Information
Summary
● Use Case Name: Tên Use Case
 ● Use Case ID: Mã Use Case
● Use Case Description: Tóm gọn nhanh sự tương tác được thể hiện trong Use Case
là gì.
● Actor: Những đối tượng thực hiện sự tương tác trong Use Case.
● Priority: Mức độ ưu tiên của Use Case so với các Use Case còn lại trong dự án.
● Trigger: Điều kiện kích hoạt Use Case xảy ra.
● Pre-Condition: Điều kiện cần để Use Case thực hiện thành công.
● Post-Condition: Những thứ sẽ xuất hiện sau khi Use Case được thực hiện thành
công
Flow
● Basic Flow: luồng tương tác CHÍNH giữa các Actor và System để Use Case thực
hiện thành công.
● Alternative Flow: luồng tương tác THAY THẾ giữa các Actor và System để Use
Case thực hiện thành công.
● Exception Flow: luồng tương tác NGOẠI LỆ giữa các Actor và System mà Use
Case thực hiện thất bại.
Additional information
● Business Rule: các quy định về mặt Business mà hệ thống bắt buộc phải nghe
theo, làm theo.
● Non-Functional Requirement: Vì Use Case chỉ dùng để thể hiện Functional
Requirement, nên anh em phải bổ sung các yêu cầu về Non-Functional ở đây luôn.

Đặc tả Use case đặt hàng

Use Case ID UC – 1
Use Case Name Đặt hàng
Description Là khách hàng, tôi muốn đặt hàng từ website
Actor(s) Khách hàng
Priority Must have
Người dùng muốn thực hiện tính năng đặt hàng từ trang website của công ty
Trigger
● Thiết bị của người dùng đã được kết nối internet khi truy cập vào trang web.
● Người dùng đã có tài khoản trên trang web.
Pre-Condition(s) ● Tài khoản tín dụng của khách hàng phải được kiểm tra và phải đủ khả năng thanh
toán.
● Các thông tin về đơn hàng phải có sẵn.

Post-Condition(s) ● Người dùng truy cập vào trang web đặt hàng thành công.
 ● Hệ thống ghi nhận thông tin đặt hàng.

1. Người dùng truy cập vào website để đặt hàng.

2. Người dùng chọn sản phẩm trong danh mục sản phẩm để đặt hàng.
3. Hệ thống hiển thị màn hình điền thông tin đơn hàng (bao gồm thông tin khách hàng và
Basic Flow sản phẩm).
4. Người dùng nhập thông tin và kiểm tra thông tin đơn hàng và xác nhận đơn hàng.
5. Hệ thống xác nhận thông tin đơn hàng và cho phép đặt hàng.
6. Hệ thống hiển thị thông báo đã đặt hàng thành công.
2a. Người dùng nhập từ khóa sản phẩm trên thanh tìm kiếm của website.
2a1. Hệ thống hiển thị màn hình các sản phẩm đang tìm kiếm.
Alternative Flow
2a2. Người dùng chọn sản phẩm để đặt hàng.
Use case tiếp tục bước 3.
2b. Người dùng không tìm thấy sản phẩm để đặt hàng.
Use case dừng lại
2c. Người dùng chọn sản phẩm để đặt hàng nhưng sản phẩm hết hàng.
Exception Flow Use case dừng lại
4a. Người dùng xác nhận thông tin đơn hàng không thành công và hiển thị thông báo.
5a. Hệ thống báo lỗi và hủy bỏ lệnh xác nhận thông tin đơn hàng.
Use case dừng lại.
Business Rules BR1 – 1: Người dùng nhập thông tin sai lần thứ 10 sẽ hiện ra thông báo liên hệ nhân viên.
NFR1 – 1: Time out cho màn hình xác nhận thông tin dưới 3 phút.
NFR1 – 2: Khi người dùng thực hiện một thao tác lỗi, hệ thống sẽ hiển thị ra một pop up
message để thông báo lỗi và hướng dẫn cách khắc phục.
Non-Functional NFR1 – 3: Tự động hóa điền thông tin khách hàng cho người dùng đặt hàng từ lần thứ 2
Requirement trở lên.
NFR1 – 4: Gợi ý các sản phẩm kèm theo hoặc các sản phẩm tương tự với sản phẩm mà
người dùng đặt.

Đặc tả Use case theo dõi đơn hàng

Use Case ID UC – 2
Use Case Name Theo dõi đơn hàng
Description Là khách hàng, tôi muốn theo dõi đơn hàng đã đặt
Actor(s) Khách hàng
Priority Must have
Trigger Người dùng muốn biết tình trạng của đơn hàng đã đặt.
● Thiết bị của người dùng đã được kết nối internet khi truy cập vào trang web.
● Người dùng phải có tài khoản trên trang web để lưu thông tin đơn hàng trên trang
Pre-Condition(s) web.
● Phải có ít nhất một sản phẩm đã đặt hàng trên trang web.
● Mã của đơn hàng đã được ghi nhận trong hệ thống.

● Người dùng truy cập vào được trang tình trạng của đơn hàng.
Post-Condition(s)
 ● Hệ thống hiển thị tình trạng của đơn hàng.

1. Người dùng truy cập vào website của công ty.

2. Người dùng chọn tính năng theo dõi đơn hàng và chọn phương thức tra cứu bằng
mã đơn hàng.
3. Hệ thống hiển thị ra ô nhập mã đơn hàng.
Basic Flow
4. Người dùng nhập mã đơn hàng cần theo dõi và bấm tìm kiếm.
5. Hệ thống đọc mã đơn hàng, mã đơn hàng đúng, hệ thống xác nhận đơn hàng tồn
tại.
6. Hệ thống hiển thị đơn hàng và cho phép người dùng xem tình trạng đơn hàng.
2a. Người dùng chọn phương thức tra cứu đơn bằng bằng mã vạch.
2a1. Hệ thống cho phép người dùng tra cứu bằng mã vạch.
2a2. Người dùng quét mã vạch bằng camera và thực hiện quét.
Use Case tiếp tục UC2 – 5
2a3. Người dùng quét mã vạch thông qua mã vạch có sẵn và thực hiện quét mã vạch.
Use Case tiếp tục UC2 – 5
Alternative Flow
2b. Người dùng chọn phương thức tra cứu qua tài khoản.
2b1. Người dùng đăng nhập vào tài khoản trên website và truy cập vào mục lịch sử
mua hàng.
2b2. Hệ thống hiển thị ra danh sách các đơn hàng đã đặt.
2b3. Người dùng chọn đơn hàng cần theo dõi và xem tình trạng đơn hàng.
Use Case dừng lại.
4a. Người dùng nhập sai mã đơn hàng
5a. Hệ thống xác thực mã đơn hàng không tồn tại, hiển thị ra thông báo và hủy bỏ
Exception Flow lệnh nhập mã đơn hàng.
Use Case dừng lại.
BR2 – 1: Người dùng nhập mã đơn hàng sai lần thứ 10 sẽ hiện ra thông báo liên hệ
Business Rules nhân viên.
NFR2 – 1: Khi người dùng thực hiện một thao tác lỗi, hệ thống sẽ hiển thị ra một pop
up message để thông báo lỗi và hướng dẫn cách khắc phục.
NFR2 – 2: Thông báo tình trạng của đơn hàng cho người dùng theo từng giai đoạn qua
Non-Functional
SMS, hoặc email
Requirement
NFR2 – 3: Cập nhập thêm tính năng tra cứu đơn hàng qua bên thứ ba hoặc bên vận
chuyển.