SSA Phụ Huynh
Nội dung trình bày
1 / 23

SSA Phụ Huynh

Hai ứng dụng: Web Admin cho SSA, Zalo Mini App cho phụ huynh.

Xem tính năng

  • Đã chọn hướngAirflow, VPS Việt Nam và Cloudflare. Không dùng Apps Script.
  • Cần chốt trước dữ liệu thậtNơi xử lý/lưu trữ và mô hình cửa hàng.
  • Hiện có UI mockAdmin và MiniApp đã có UI mock; chưa có backend, thanh toán hoặc gửi tin thật.

Hồ sơ kỹ thuật cho đội triển khai

Tính năng Mini App

Sơ đồ Phạm vi sản phẩmSơ đồ Phạm vi sản phẩmPhạm vi sản phẩm

Phụ huynh và SSA cần những module nào? Mở sơ đồ tương tác

Zalo Mini App: một tài khoản, đúng phạm vi từng con. UI hiện có năm tab: Trang chủ, Kết quả, Cửa hàng, Thông báo và Hồ sơ. Khảo sát vẫn thuộc phạm vi cần bổ sung.

  • Tài khoản: liên kết và chọn con đã được SSA xác minh.
  • Trang chủ: lớp, lịch, sân, điểm danh và số buổi còn lại.
  • Kết quả: chọn kỳ, 6 kỹ năng/5 mức, so sánh kỳ trước, nhận xét, mục tiêu và phiếu xem thử; PDF đã duyệt cần backend.
  • Thông báo/khảo sát: inbox trong app + ZNS/ZBS theo sự kiện, deep link đúng quyền; khảo sát không trùng câu trả lời.
  • Cửa hàng: chọn sản phẩm, size/màu, số lượng, ghi chú và đăng ký mua tạo đơn mock. Checkout SDK, thanh toán và hoàn tiền thật vẫn cần tích hợp.

Mock chưa nối backend, không có thanh toán online. Phạm vi mới đã bổ sung: Notification/ZBS, Checkout và quản lý đơn/thanh toán; Admin có merchandise, quản lý thanh toán và audit nguồn thu. Đặc tả bổ sung. Chi tiết Mini App/Admin. Phạm vi và tiêu chí đạt

MiniApp hiện có: việc học của con

Chọn con, xem kỳ đánh giá và mở hồ sơ trong một giao diện thống nhất.

Chọn con, lịch học, gói học và điều hướng năm tab.
Chọn con và xem lịchMA-01 — UI mock
Kỳ đánh giá, kỹ năng và nội dung phiếu mẫu.
Theo dõi từng kỳMA-02 — UI mock
Thông tin hồ sơ và các tùy chọn hiện có.
Hồ sơ và tùy chọnMA-03 — UI mock

Ảnh từ browser preview, dữ liệu mẫu. Chưa phải nghiệm thu trên Zalo runtime. Mở ảnh đầy đủ và phạm vi chứng minh.

MiniApp hiện có: cửa hàng và thông báo

Đăng ký mua tạo đơn mẫu; thông báo có nội dung và điểm vào xử lý.

Danh mục sản phẩm mẫu và giá niêm yết.
Danh mục merchandiseMA-04 — UI mock
Đơn được tạo bằng UI và trạng thái xử lý mẫu.
Đơn tạo từ UIMA-06 — UI mock
Nội dung thông báo và nút báo lý do nghỉ.
Thông báo có điểm vàoMA-07 — UI mock

Đơn này được tạo bằng thao tác UI. Chưa có Checkout hoặc gửi ZNS thật; store mock của hai app độc lập. Xem kịch bản chụp.

Tính năng Web Admin

Sơ đồ Nguồn sự thậtSơ đồ Nguồn sự thậtNguồn sự thật

Field nào thuộc MISA, quyền và giao dịch thuộc ai? Mở sơ đồ tương tác

Web Admin: một giao diện nội bộ, menu theo vai trò. Bản mock hiện có 19 màn hình và sáu vai trò: vận hành, Coach, bán hàng, tài chính, người duyệt và quản trị hệ thống.

  • Vận hành: dashboard công việc, hồ sơ/lớp, import, kiểm tra dữ liệu và xác minh liên kết.
  • Người duyệt: duyệt dữ liệu, phiếu Coach/PDF, thông báo và lịch phát hành.
  • Coach/chăm sóc: soạn đánh giá, quản lý đợt khảo sát và xử lý phản hồi thấp.
  • Sale/merchandise: catalog, SKU/giá/tồn, xuất bản và xử lý giao/nhận đơn.
  • Tài chính: quản lý giao dịch, pending và lập yêu cầu hoàn; người duyệt phê duyệt riêng. Đối soát nguồn thu, phí và tiền thực nhận.
  • Quản trị hệ thống: nhân sự/quyền, yêu cầu dữ liệu và delivery mẫu; sao lưu/phục hồi hạ tầng vẫn là thiết kế đề xuất.

Tính năng Web Admin và module bổ sung, ma trận quyền và hướng dẫn vận hành dùng để giao việc khi triển khai.

Admin hiện có: báo cáo vận hành

Chọn kỳ, đọc biểu đồ và xác định công việc trong phạm vi vai trò.

Bộ lọc ngày và nhóm ngày/tuần/tháng.
Chọn ngày và cách gộpAD-02-F — UI mock
Vùng biểu đồ tài chính và snapshot chuyên cần.
Đọc biểu đồ cùng chú thíchAD-02-C — UI mock

Vận hành; dữ liệu 01–12/11/2026. Tiền hoàn là lũy kế hiện tại; chuyên cần là snapshot. Xem ảnh toàn màn hình.

Admin hiện có: thanh toán và đối soát

Giao dịch và khoản thực nhận có màn hình đối chiếu riêng.

Vùng thông tin giao dịch trong drawer.
Tài chính: giao dịchAD-04-D — UI mock
Vùng thông tin và trạng thái kỳ đối soát.
Tài chính: kỳ đối soátAD-05-D — UI mock

Vai trò tài chính. Ảnh chứng minh giao diện mock; chưa chứng minh tiền đã được thu hoặc chuyển về ngân hàng. Xem phạm vi từng ảnh.

Admin hiện có: dấu vết thay đổi

Một lần sửa qua UI tạo bản ghi audit với dữ liệu trước và sau.

Chi tiết trước/sau của lần cập nhật HV001.
Vận hành: trước thay đổiAD-06-D — UI mock
Giá trị buổi còn lại là 9 trong dữ liệu sau của audit.
Vận hành: sau thay đổiAD-06-A — UI mock

Vận hành đổi buổi còn lại của HV001 từ 3 thành 9 trong phiên demo riêng. Đây là audit local, chưa phải log bất biến phía server. Xem bằng chứng và kịch bản.

Luồng cập nhật dữ liệu

Sơ đồ Duyệt và publish MISASơ đồ Duyệt và publish MISADuyệt và publish MISA

Khi nào file mới được phép xuất hiện trên màn hình? Mở sơ đồ tương tác

Số mới chỉ xuất hiện sau khi SSA duyệt.

  • SSA xuất file MISA; Airflow điều phối nhận và kiểm tra.
  • Mỗi đợt MVP đều chờ người có quyền duyệt đối soát.
  • File lỗi hoặc chưa được duyệt: giữ phiên bản đang phục vụ.

Lịch chạy không làm file cũ thành dữ liệu mới. Director cần chốt người xuất, người duyệt và giờ cập nhật. Xem luồng import tương tác

Hành trình phụ huynh

Sơ đồ Xác thực và quyền trẻSơ đồ Xác thực và quyền trẻXác thực và quyền trẻ

Điều gì cho phép một phụ huynh xem một trẻ? Mở sơ đồ tương tác

Đăng nhập Zalo chưa đủ để xem hồ sơ trẻ.

  • SSA xác minh quan hệ trước khi cấp quyền.
  • Không khớp hồ sơ: chuyển hỗ trợ, không gợi ý danh sách trẻ.
  • Đổi con: màn hình đổi đúng phạm vi dữ liệu.
  • Gỡ quyền: lần truy cập tiếp theo phải bị chặn.

Nghiệm thu bằng tài khoản phụ huynh thường, cả tình huống từ chối quyền và nhiều con. Xem các bước kiểm quyền

Luồng nhận xét và chăm sóc

Sơ đồ Phiếu Coach và PDFSơ đồ Phiếu Coach và PDFPhiếu Coach và PDF

Ai duyệt nội dung trước khi phụ huynh đọc? Mở sơ đồ tương tác

Người thật duyệt nội dung; hệ thống giữ dấu vết.

  • Phiếu tháng: Coach gửi, người phụ trách duyệt, phụ huynh xem PDF đúng phiên bản. AI chỉ hỗ trợ câu chữ khi được cho phép.
  • Khảo sát/thông báo: chọn đúng nhóm, phát hành, theo dõi phản hồi và giao việc chăm sóc.
  • Thương mại: đơn → Checkout → server xác nhận tiền → giao/nhận → đối soát; inbox/ZBS theo từng sự kiện.

Gửi lại không tạo hai đơn hoặc hai việc chăm sóc. Khảo sát / Cửa hàng

Merchandise: từ catalog đến giao nhận

Sơ đồ Merchandise và tồn khả dụngSơ đồ Merchandise và tồn khả dụngMerchandise và tồn khả dụng

Ai duyệt sản phẩm, giữ hàng và xử lý tiền đến muộn? Mở sơ đồ tương tác

Giá và tồn được kiểm soát trước khi phụ huynh thanh toán. Catalog xuất bản theo quyền; đơn giữ giá chốt. Hết hạn giữ hàng nhưng tiền tới muộn phải được xử lý riêng.

Checkout: server xác nhận tiền

Sơ đồ Từ đơn đến tiền thực nhậnSơ đồ Từ đơn đến tiền thực nhậnTừ đơn đến tiền thực nhận

Checkout, giao hàng và đối soát nối nhau ra sao? Mở sơ đồ tương tác

Đơn hàng, thanh toán và tiền thực nhận là ba trạng thái riêng. SDK là cửa vào thanh toán; backend xác minh giao dịch trước khi ghi nhận thu. Xem sequence kỹ thuật.

Thông báo đúng người, đúng sự kiện

Sơ đồ Notification và ZNS/ZBSSơ đồ Notification và ZNS/ZBSNotification và ZNS/ZBS

Inbox và gửi tin Zalo khác nhau ở đâu? Mở sơ đồ tương tác

Inbox Mini App và ZNS/ZBS là hai kênh riêng. Gửi sau commit, kiểm quyền trước gửi/mở; gửi tin lỗi không làm mất đơn hoặc thu lại tiền.

Hủy đơn và hoàn tiền có kiểm soát

Sơ đồ Hủy đơn và hoàn tiềnSơ đồ Hủy đơn và hoàn tiềnHủy đơn và hoàn tiền

Ai yêu cầu, ai duyệt và khi nào xác nhận đã hoàn? Mở sơ đồ tương tác

Hủy đơn không có nghĩa tiền đã được hoàn. Người lập khác người duyệt; xác nhận kết quả provider và chống hoàn trùng. Trường hợp chưa rõ phải được tra cứu.

Audit nguồn thu và khoản thực nhận

Sơ đồ Đối soát nguồn thuSơ đồ Đối soát nguồn thuĐối soát nguồn thu

Tiền thu, phí, hoàn và khoản thực nhận khớp thế nào? Mở sơ đồ tương tác

Truy từ đơn tới giao dịch, phí, hoàn và tiền về tài khoản. Khoản lệch có người xử lý và bằng chứng; người lập không tự duyệt đối soát. ERD thanh toán / ERD settlement.

Khi có số liệu sai

Sơ đồ Phục hồi và đối soátSơ đồ Phục hồi và đối soátPhục hồi và đối soát

Khôi phục mà không mất giao dịch mới thế nào? Mở sơ đồ tương tác

Truy về nguồn trước khi sửa. “8 buổi thành 2” là tình huống kiểm thử, chưa phải sự cố đã xác nhận tại SSA.

  • Vận hành tìm file, dòng nguồn và đợt cập nhật liên quan.
  • Người duyệt xác nhận cách sửa hoặc quay về bản dữ liệu trước.
  • Kỹ thuật ghi nhật ký; SSA đối soát lại kết quả.

Không sửa âm thầm hoặc đảo ngược đơn, quyền và khảo sát mới. Hồ sơ xử lý và phục hồi

Các phần của hệ thống

Sơ đồ Đường gọi phụ huynhSơ đồ Đường gọi phụ huynhĐường gọi phụ huynh

Request đi qua proxy và kiểm quyền thế nào? Mở sơ đồ tương tác

Tách luồng phụ huynh khỏi luồng cập nhật dữ liệu.

  • Mini App: xem thông tin và gửi yêu cầu.
  • Admin/Airflow: nhân sự duyệt, lịch cập nhật được theo dõi.
  • VPS Việt Nam: tiếp nhận rồi chuyển yêu cầu đến Cloudflare.
  • Cloudflare: xử lý nghiệp vụ, dữ liệu, file và tác vụ nền.

Proxy ở Việt Nam chưa chứng minh dữ liệu Cloudflare lưu tại Việt Nam. Mỗi phần cần kiểm thử và người vận hành. Kiến trúc kỹ thuật và sơ đồ tương tác

Từ demo đến vận hành

Nghiệm thu bằng kết quả và trách nhiệm bàn giao. Kỹ sư cũng có thể dùng AI; “Vibecode” mô tả cách làm nhanh, không tự chứng minh chất lượng thấp.

Demo chứng minh Trước vận hành phải chứng minh thêm
Màn hình, luồng thuận Dữ liệu đối soát, đúng quyền, gửi lại an toàn
Bản chạy thử Zalo phát hành, cảnh báo và phục hồi đã thử
Ý tưởng khả thi SSA giữ source/tài khoản; rõ chi phí, hỗ trợ và bảo trì

Hai cách làm chịu cùng tiêu chí. Ma trận đánh giá đội triển khai

Giới hạn phương án Apps Script

Apps Script đã bị loại khỏi hệ thống đích. Chưa có source/runtime để kết luận phương án cũ đã lỗi hoặc không đủ tải.

Thiết kế mới dùng đối soát, duyệt rồi công bố phiên bản dữ liệu. Đổi công nghệ không thay việc nghiệm thu. Hạn mức và nguồn Google chính thức

Giới hạn của kiến trúc mới

Hướng mới vẫn cần nguồn đúng và người trực.

Nếu A không đáp ứng, B là phương án dự phòng phải được SSA duyệt. Xem phương án B

Thứ tự triển khai và nghiệm thu

Sơ đồ Lộ trình và exit gatesSơ đồ Lộ trình và exit gatesLộ trình và exit gates

Được chuyển bước khi có kết quả gì? Mở sơ đồ tương tác

Chuyển bước khi có bằng chứng, không chỉ khi code xong.

  1. Khảo sát: chốt nguồn, quy tắc, phạm vi, nơi dữ liệu và cửa hàng.
  2. Xây và thử: đúng quyền, đúng số liệu, gửi lại an toàn.
  3. Pilot: SSA ký đối soát; thử phục hồi; Zalo duyệt và phát hành.
  4. Bàn giao: source, tài khoản, người trực, cảnh báo và hỗ trợ.

Baseline 6 đến 10 tuần cần tính lại sau bổ sung Airflow/VPS; chưa cam kết ngày live hoặc ngân sách. Luồng phát hành

Các quyết định Director cần chốt

Mỗi quyết định cần một người chịu trách nhiệm và đầu ra để duyệt.

Cần chốt Người phụ trách Đầu ra
Thương mại/thanh toán Director + nghiệp vụ + tài chính Provider/merchant, nhận hàng, hủy/hoàn, nguồn thu và settlement
Quyền/dữ liệu SSA dữ liệu + kỹ thuật Xác minh, consent, nơi xử lý
Lịch/nhân sự SSA vận hành + đối tác Người xuất, duyệt và trực
Ngân sách/nghiệm thu Director + lead triển khai Dự toán mới; tiêu chí, bàn giao, bảo trì

Có thể duyệt hướng và phạm vi; chưa xác nhận sẵn sàng vận hành. Đọc kế hoạch triển khai đầy đủ | Xem sơ đồ chi tiết