Bỏ qua điều hướng
Kiến thức website

Website chuyển lớp: giữ đúng số buổi học còn lại

Học viên học sáu buổi rồi chuyển lớp. Nhân viên nhập lại gói mười buổi ở lớp mới, và website hiển thị còn mười buổi. Nếu gói ban đầu chỉ có mười buổi và…

Chia sẻFacebookLinkedInZalo
Phòng học trống với bàn ghế và bảng viết trong ánh sáng tự nhiên
Nội dung bài viết

Học viên học sáu buổi rồi chuyển lớp. Nhân viên nhập lại gói mười buổi ở lớp mới, và website hiển thị còn mười buổi. Nếu gói ban đầu chỉ có mười buổi và không có quyền lợi bổ sung, hệ thống đã cấp thừa sáu buổi. Website chuyển lớp cần giữ được sổ buổi học còn lại, không coi một lần đổi lớp là một lần mua gói mới.

Dưới đây là mô hình nghiệp vụ đề xuất để làm rõ quyền học, nơi xếp lịch và lịch sử điều chỉnh. Ví dụ dùng các buổi giả định, không đưa ra chính sách hoàn phí, chuyển đổi học phí hoặc quy định học vụ áp dụng cho mọi trung tâm.

Website chuyển lớp phải giữ nguyên một sổ quyền học

Giả sử học viên có quyền học mười buổi. Sau sáu buổi đã được ghi nhận sử dụng theo chính sách, số còn lại là bốn. Chuyển từ lớp A sang B chỉ đổi nơi học của phần còn lại nếu trung tâm cho phép như vậy. Nó không tự tạo thêm mười buổi và cũng không tự xóa sáu buổi đã sử dụng. Đây là điểm khởi đầu cần thống nhất trước khi vẽ màn hình chuyển lớp.

Trong mô hình này có ba loại bản ghi. Gói hoặc quyền học xác định học viên được sử dụng gì. Lượt xếp lớp xác định học viên tham gia lớp nào trong giai đoạn nào. Sự kiện sử dụng hoặc điều chỉnh ghi lại tác động đến số dư. Tên gọi có thể thay đổi theo phần mềm; điều quan trọng là ba chức năng không bị ép vào một trường “lớp hiện tại”.

Nếu chuyển lớp được thực hiện bằng cách xóa ghi danh cũ rồi tạo một ghi danh đầy đủ mới, đội triển khai cần chứng minh lịch sử và số dư vẫn được bảo toàn. Một màn hình chỉ còn thấy lớp B có thể thuận tiện cho giáo viên hiện tại nhưng không đủ để giải thích vì sao học viên còn bốn buổi.

HubSpot mô tả quan hệ giữa các bản ghi CRM như một cách giữ các đối tượng riêng mà vẫn liên kết được. Đây là nguyên tắc dữ liệu tham khảo, không phải tuyên bố HubSpot có sẵn sổ buổi học. Sổ quyền học trong bài là thiết kế cần được triển khai hoặc ánh xạ vào hệ thống học vụ phù hợp.

Một sự kiện chuyển cần có mã, học viên, gói nguồn, lớp nguồn, lớp đích, ngày hiệu lực và người xác nhận. Ghi lý do ở mức cần thiết cho vận hành. Nếu phần mềm có nhiều hệ thống cùng tham gia, mã này cũng giúp đối chiếu thao tác ở website và hệ thống học vụ mà không phải tìm bằng tên học viên.

Sơ đồ website chuyển lớp với sáu buổi đã dùng và bốn buổi còn lại
Ví dụ minh họa: đổi lớp không tự cấp lại số buổi đã sử dụng.

Đặt sự kiện lên sổ trước khi tính số dư

Sổ có thể bắt đầu bằng cấp quyền mười buổi, sau đó trừ các buổi được xác nhận đã dùng. Bảo lưu, nghỉ có phép, học bù hoặc điều chỉnh có thể tác động khác nhau tùy chính sách. Không nên mặc định mọi dòng điểm danh đều trừ một buổi, cũng không mặc định buổi vắng luôn được giữ lại. Trung tâm phải xác định rõ sự kiện nào thay đổi quyền học.

Sự kiện giả định Tác động trong ví dụ Cần đối chiếu
Cấp gói ban đầu Cộng 10 buổi Đúng gói và người học
Sáu buổi đã sử dụng Trừ 6 buổi Từng sự kiện không trùng
Chuyển lớp A sang B Không cộng lại quyền học Ngày hiệu lực và lớp đích
Điều chỉnh được duyệt Theo chính sách cụ thể Lý do, người duyệt, tham chiếu

Bảng trên chỉ minh họa một chính sách đơn giản. Nếu lớp mới có thời lượng hoặc giá trị mỗi buổi khác, không thể tự suy ra bốn buổi cũ bằng bốn buổi mới. Có thể cần một phép quy đổi được doanh nghiệp duyệt hoặc xử lý thủ công. Website phải trình bày điều kiện đó trước khi xác nhận, không dùng phép chia học phí ngầm để quyết định thay trung tâm.

Sự kiện sử dụng cần gắn với buổi học hoặc hoạt động cụ thể. Nếu đồng bộ được gửi lại sau timeout, không được trừ thêm lần thứ hai. Khóa chống trùng phải nhận diện đúng sự kiện đã ghi, không chỉ so số dư cuối vì hai giao dịch khác nhau có thể tình cờ tạo cùng con số.

Sửa điểm danh cũ sau ngày chuyển là một ca đáng chú ý. Nếu buổi thứ sáu bị nhập nhầm, hệ thống cần ghi điều chỉnh có tham chiếu đến sự kiện gốc, thay vì âm thầm tăng số dư không có lý do. Cách làm giữ được khả năng giải thích lịch sử mà không yêu cầu lưu mọi bản chụp màn hình.

Tài liệu Associations API của HubSpot cho thấy liên kết bản ghi là thao tác riêng với định danh hai đầu. Khi nối với sổ quyền học, một liên kết thành công không tự chứng minh phép cộng trừ hoặc quy tắc học bù đã đúng. Đó vẫn là phần nghiệp vụ phải kiểm tra riêng.

Chuyển chỗ học cần chốt cả lớp nguồn lẫn lớp đích

Trước ngày hiệu lực, giáo viên lớp A có thể vẫn cần thấy học viên trong danh sách. Sau ngày hiệu lực, lớp B cần nhận đúng lịch học còn lại. Chỉ đổi tên lớp trên hồ sơ chung có thể làm lịch sử buổi trước đó hiển thị như đã diễn ra ở lớp B. Lịch sử phải phản ánh nơi học thực tế tại thời điểm xảy ra.

Lớp B cũng cần đủ chỗ và phù hợp với quyết định học thuật. Số dư bốn buổi không có nghĩa trung tâm có thể xếp bốn buổi bất kỳ. Nếu lớp đích hết chỗ, quy trình chuyển chưa hoàn thành; không nên giải phóng lớp nguồn rồi phát hiện không có nơi tiếp nhận. Cơ chế giữ chỗ và thứ tự xác nhận cần được thống nhất theo hệ thống vận hành.

Một lần chuyển có thể tạo yêu cầu, được duyệt, chờ ngày hiệu lực rồi hoàn tất. Các trạng thái này nên phục vụ công việc thực tế, không tăng số bước chỉ để làm quy trình trông phức tạp. Quan trọng nhất là biết khi nào lớp nguồn thôi chịu trách nhiệm, lớp đích bắt đầu chịu trách nhiệm và số dư đang được sử dụng ở đâu.

Odoo Appointments là nguồn tham khảo về lịch theo người hoặc tài nguyên. Việc một lịch mới được tạo không tự điều chuyển quyền học từ lớp cũ. Nếu dùng một công cụ lịch trong giải pháp, cần thêm liên kết và quy tắc nghiệp vụ để ngăn một học viên dùng cùng phần quyền ở hai nơi ngoài phạm vi cho phép.

Trong giai đoạn chuyển tiếp, nếu hệ thống cho phép học song song có chủ đích, mỗi buổi vẫn phải trừ đúng cùng sổ hoặc đúng quyền được phân bổ. Không nên chặn mọi trường hợp song song bằng một cờ chung nếu trung tâm thực sự có chính sách học bù, nhưng cũng không để hai lớp tự cấp lịch từ hai bản số dư sao chép.

Một sổ quyền học ở giữa nối với lớp cũ và lớp mới theo hai giai đoạn
Ví dụ biên tập: hai lớp tham chiếu cùng lịch sử quyền học, không tạo hai số dư độc lập.

Đối chiếu một lần chuyển bằng câu chuyện đọc được

Người học nên xem được một bản tóm tắt rõ: đã sử dụng bao nhiêu theo chính sách, phần nào còn hiệu lực, chuyển từ ngày nào và lớp nào tiếp nhận. Không cần đưa mã kỹ thuật hoặc trạng thái tích hợp lên màn hình dành cho phụ huynh. Nếu chưa duyệt quy đổi, hãy nói phần đó đang được xác nhận thay vì hiển thị một số dư chắc chắn.

Buổi nghiệm thu nên đi qua gói mười buổi, sáu lần sử dụng, chuyển lớp và một buổi ở lớp mới. Trong mô hình đơn giản đã chọn, sau buổi mới còn ba. Gửi lại sự kiện chuyển không được cấp thêm quyền; gửi lại sự kiện điểm danh không được trừ thêm. Sau đó hủy yêu cầu chuyển trước hiệu lực để kiểm tra lớp nguồn và số dư được giữ đúng.

Thử thêm một điều chỉnh điểm danh cũ, lớp đích hết chỗ và gói đã hết hiệu lực theo chính sách. Những ca này giúp phân biệt lỗi dữ liệu với trường hợp cần người có thẩm quyền quyết định. Không dùng tự động hóa để tạo ngoại lệ học vụ hoặc thương mại khi trung tâm chưa xác nhận quy tắc.

Nếu muốn xây website kết nối hệ thống quản lý học viên, hãy chuẩn bị một gói giả lập cùng lịch sử sử dụng và tình huống chuyển lớp. Giá: Liên hệ. Nhận tư vấn & báo giá theo dữ liệu cần bảo toàn và phạm vi bàn giao, không chỉ theo số màn hình quản trị.

KHÁM PHÁ ONTER

Tìm kiếm trên Onter

Nhập từ khóa để tìm nội dung phù hợp

↑ ↓ chọn · Enter mở · Esc đóngXem tất cả kết quả →

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo