Nhân viên hiện trường, nhân viên bán hàng và tài xế không phải lúc nào cũng làm việc trước màn hình máy tính. Họ cần tra cứu dữ liệu và cập nhật tình trạng công việc ngay trên điện thoại. Tuy nhiên, không phải nghiệp vụ nào cũng cần phát triển một ứng dụng native riêng.
Trước khi tích hợp Odoo với Android hoặc iOS, doanh nghiệp nên xác định vai trò người dùng, điều kiện kết nối và mức độ cập nhật thời gian thực. Đây là cơ sở để chọn mobile web, PWA, ứng dụng có sẵn hay app tùy chỉnh.
Các kịch bản di động phổ biến
Nhiều dự án chỉ cần vài hành động chính trên app: nhận đơn, tra cứu tồn kho, quét mã, xác nhận giao hàng hoặc chụp ảnh chứng từ. Không nên bê nguyên toàn bộ giao diện ERP lên điện thoại.
Một trải nghiệm tốt thường có danh sách công việc, màn hình chi tiết và một thao tác xác nhận dễ sử dụng bằng một tay.
- Sales: khách hàng, báo giá, đơn hàng được phân công
- Kho: quét mã, xác nhận nhập/xuất
- Giao nhận: chuyến đi, POD, COD, lý do giao thất bại
- Dịch vụ: ticket, ảnh hiện trường, thời gian thực hiện
Thiết kế API và phân quyền Odoo
Ứng dụng chỉ nên truy cập những model và trường thực sự cần thiết. API cần kiểm tra quyền ở server, không chỉ ẩn nút trên điện thoại. Với Odoo 19, cần đánh giá External JSON-2 API và điều kiện gói dịch vụ; không giả định mọi bản Odoo Online đều cho phép API tùy ý.
Thiết kế token, vòng đời phiên và cơ chế thu hồi quyền là một phần của hợp đồng tích hợp, đặc biệt khi nhân viên dùng thiết bị cá nhân.
- API định nghĩa rõ dữ liệu đọc/ghi theo vai trò
- Không chứa thông tin đăng nhập quản trị trong ứng dụng
- Chặn cập nhật trái quyền ở phía máy chủ
- Giới hạn log có chứa thông tin cá nhân
Khi mất mạng: offline và đồng bộ lại
Ứng dụng ngoài hiện trường có thể mất mạng giữa lúc ký nhận hàng. Nếu phải hỗ trợ offline, cần quy định dữ liệu được lưu cục bộ, thứ tự đồng bộ và cách phát hiện xung đột khi cùng một đơn đã được sửa trên server.
Đồng bộ thử lại tự động không được tạo hai phiếu xuất kho hoặc hai lần xác nhận COD.
- Thiết kế hàng đợi thao tác khi offline
- Mã thao tác idempotent để chống trùng
- Hiển thị trạng thái đang chờ đồng bộ cho người dùng
- Cho phép xử lý xung đột theo quy trình kiểm soát
Nghiệm thu ứng dụng di động
Ngoài luồng thành công, cần thử thiết bị cấu hình yếu, mạng 4G không ổn định, đăng xuất từ xa, thiết bị bị mất và phiên hết hạn. Kết quả kiểm thử nên tách lỗi app, lỗi API và lỗi từ Odoo.
Nếu dự án có phát hành Google Play/App Store, phải dự trù tài khoản nhà phát triển, chính sách riêng tư và thời gian xét duyệt ngoài phạm vi lập trình.
- Đăng nhập, phân quyền, thu hồi token
- Đồng bộ trạng thái sau mất mạng
- Kiểm tra tải dữ liệu lớn và ảnh nén
- Bàn giao source app, API spec và tài liệu vận hành
Trước tiên phải chọn đúng loại ứng dụng di động
| Lựa chọn | Phù hợp khi | Phạm vi triển khai |
|---|---|---|
| Ứng dụng Odoo có sẵn | Người dùng cần truy cập các chức năng Odoo hiện hữu | Cấu hình quyền, giao diện và quy trình |
| Ứng dụng riêng cho nhân viên | Cần thao tác đơn giản, camera, GPS hoặc làm việc ngoài hiện trường | Thiết kế app, API, đăng nhập và đồng bộ |
| Ứng dụng cho khách hàng/đối tác | Cần trải nghiệm và thương hiệu riêng | API công khai có kiểm soát, hồ sơ người dùng và quy trình duyệt |
Không nên phát triển app riêng chỉ để sao chép toàn bộ màn hình Odoo. App nên tập trung vào các tác vụ di động có tần suất cao như chụp ảnh, quét mã, xác nhận giao hàng, kiểm kê hoặc phê duyệt nhanh.
Yêu cầu kỹ thuật và nghiệm thu
- Mỗi API có người dùng, quyền, dữ liệu đầu vào và lỗi trả về được mô tả.
- Token truy cập được lưu an toàn, có thời hạn và cơ chế thu hồi.
- Dữ liệu nhạy cảm không lưu trên thiết bị nếu không thật sự cần.
- Chế độ mất mạng quy định rõ dữ liệu nào xem được, sửa được và thời điểm đồng bộ.
- Cơ chế thử lại tự động chống gửi trùng giao dịch khi mạng chập chờn.
- Kiểm thử trên phiên bản Android/iOS, kích thước màn hình và điều kiện mạng đã thống nhất.
Ứng dụng di động chỉ là một phần của hệ thống. Phạm vi còn bao gồm API, giám sát, hỗ trợ phiên bản hệ điều hành và quy trình phát hành lên cửa hàng ứng dụng. Xem dịch vụ phát triển ứng dụng di động và tích hợp Odoo để tách rõ trách nhiệm.
Ma trận quyết định cho ứng dụng có chế độ mất mạng
Không phải dữ liệu nào cũng nên lưu trên điện thoại. Hãy phân loại thao tác theo mức nhạy cảm, khả năng xung đột và hậu quả nếu đồng bộ chậm.
| Thao tác | Cho phép khi mất mạng? | Kiểm soát bắt buộc |
|---|---|---|
| Xem danh sách công việc đã giao | Có thể, với dữ liệu đã tải trước | Giới hạn phạm vi người dùng và thời gian lưu cục bộ |
| Tạo ghi nhận hiện trường | Có thể lưu hàng đợi | ID tạm, thời điểm thiết bị và cơ chế chống gửi trùng |
| Tải ảnh/chữ ký | Có thể xếp hàng nếu dung lượng phù hợp | Mã hóa, giới hạn kích thước và trạng thái tải |
| Phê duyệt giao dịch nhạy cảm | Thường nên yêu cầu trực tuyến | Xác thực lại, kiểm tra phiên bản dữ liệu và ghi log |
| Xem dữ liệu khách hàng nhạy cảm | Hạn chế hoặc không lưu cục bộ | Quyền tối thiểu, mã hóa và xóa từ xa khi cần |
Một kịch bản nghiệm thu tốt gồm: đăng nhập và tải dữ liệu, bật chế độ máy bay, tạo hai bản ghi, sửa cùng dữ liệu từ hệ thống khác, kết nối lại và quan sát quy tắc giải quyết xung đột. Tiếp tục thử với token hết hạn và cùng một yêu cầu được gửi lại.
Thiết kế phải nêu dữ liệu nào được lưu cục bộ, lưu bao lâu và ai có quyền xóa. Khả năng “chạy offline” không nên được chấp nhận nếu chưa có quy tắc bảo mật và đối soát sau đồng bộ.
Câu hỏi thường gặp
Có bắt buộc viết app Android và iOS riêng không?
Không. Có thể chọn mobile web/PWA hoặc app đa nền tảng nếu đáp ứng trải nghiệm và tính năng phần cứng cần dùng.
Ứng dụng có thể chạy khi mất mạng?
Có thể nếu được thiết kế offline-first; phạm vi này cần báo giá riêng vì phải xử lý cache, xung đột và đồng bộ lại.
Tư vấn phạm vi triển khai
TD Digital có thể thiết kế ứng dụng di động kết nối Odoo theo từng vai trò sử dụng. Khi khảo sát hãy cung cấp ba thao tác quan trọng nhất mà nhân viên cần làm ngoài hiện trường.
Gửi yêu cầu tư vấn / báo giá TD Digital →
Đọc thêm: Dịch vụ tích hợp Odoo · Dịch vụ phát triển ứng dụng · Lập trình module Odoo
Phạm vi Odoo được đối chiếu với tài liệu chính thức Odoo 19. Khả năng offline, sinh trắc học, thông báo đẩy và lưu dữ liệu cục bộ phụ thuộc kiến trúc ứng dụng cùng yêu cầu bảo mật đã duyệt.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.