Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Mọi phân hệ Odoo đều có dữ liệu chủ, transaction data, báo cáo và cấu hình. Nắm khung đó thì mở một module chưa từng dùng cũng đọc được trong một buổi.

Lần đầu mở màn hình chính của Odoo, bạn thấy vài chục ô vuông xếp cạnh nhau: CRM, Sales, Purchase, Inventory, Accounting, Employees, Manufacturing, Project, Website, và một loạt cái tên nữa mà bạn chưa biết dùng để làm gì.
Cách đó chạy được, nhưng nó có một vấn đề chỉ lộ ra sau vài tháng: bạn học xong năm phân hệ, tới phân hệ thứ sáu thì vẫn phải bắt đầu lại từ số không, bởi thứ bạn tích lũy được là năm chuỗi thao tác rời rạc chứ không phải một cách hiểu.
Trong công việc thật thì tình huống hay gặp lại là bạn phải mở một phân hệ chưa từng dùng và hiểu được nó trong một buổi, vì khách hàng vừa hỏi về nó trong cuộc họp sáng nay.
Vấn đề của cách học theo module không nằm ở khối lượng mà nằm ở chỗ nó không tích lũy.
Khi bạn học phân hệ Sales theo thao tác, thứ đọng lại trong đầu là một chuỗi các bước bấm, tức vào menu này, bấm nút kia, điền trường nọ. Chuỗi đó chỉ đúng cho Sales, nên tới Inventory thì bạn có một chuỗi mới hoàn toàn, tới Manufacturing lại một chuỗi nữa, và không có chuỗi nào giúp bạn đoán được chuỗi kế tiếp.
Trong khi đó các phân hệ Odoo không khác nhau nhiều tới vậy về cấu trúc. Chúng được tổ chức theo cùng một khuôn, và khuôn đó thì học một lần dùng được mãi; nắm khuôn rồi thì mỗi phân hệ mới chỉ còn là chuyện điền nội dung vào những ô đã biết trước.
Trước khi đi vào khung thì tôi nói rõ một chuyện: đây không phải quy ước mà Odoo công bố ở đâu cả, mà là cách phân loại tôi thấy dùng được trên hầu hết phân hệ, và ở buổi khai giảng khóa học của mình tôi cũng giới thiệu nó như một công cụ đọc chứ không phải luật.
Mở một phân hệ ra và nhìn thanh menu ngang, bạn sẽ thấy phần lớn các mục rơi vào bốn nhóm dưới đây. Cần lưu ý rằng thứ tự xuất hiện trên màn hình thì mỗi phân hệ một khác, nên đừng đi tìm bốn nhóm theo đúng vị trí.
Nhóm thứ nhất là dữ liệu chủ, tức những master data mà doanh nghiệp phải có trước khi vận hành. Trong phân hệ Sales thì đó là khách hàng và sản phẩm; trong phân hệ Employees thì đó là nhân viên và phòng ban. Đặc điểm nhận dạng của nhóm này là các bản ghi trong đó tồn tại độc lập, không mô tả một sự việc nào xảy ra vào một thời điểm nào, và chúng là thứ được rất nhiều đối tượng khác trỏ tới.
Nhóm thứ hai là transaction data, tức những gì phát sinh trong quá trình vận hành. Một nhân viên tạo một đơn hàng thì đơn hàng đó là transaction data. Đặc điểm nhận dạng là mỗi bản ghi ghi lại một sự việc đã xảy ra, có thời điểm, và luôn trỏ tới dữ liệu chủ.
Nhóm thứ ba là báo cáo, và nó phục vụ hai loại người đọc khác nhau là chính người thao tác hằng ngày với người quản lý ở trên. Odoo có sẵn một bộ báo cáo mặc định, tuy nhiên trong quá trình triển khai thì rất nhiều bên có nhu cầu làm thêm báo cáo theo mục đích riêng của họ, và đó là lý do nhóm menu này thường phình ra sau vài tháng vận hành.
Nhóm thứ tư là cấu hình. Nó nằm cuối menu nhưng lại là nhóm chạy đầu tiên trong thực tế, bởi có những master data và những tính năng phải được tạo ra hoặc bật lên thì hai nhóm phía trên mới vận hành được.
Trong bốn nhóm thì ranh giới giữa hai nhóm đầu là ranh giới đáng nắm nhất, vì nó quyết định thứ tự làm việc ở nhiều giai đoạn khác nhau của dự án.
Cách phân biệt nhanh là hỏi bản ghi này có mô tả một sự việc xảy ra vào một thời điểm hay không. Một khách hàng thì không, nó cứ tồn tại ở đó cho tới khi có người xóa; còn một đơn hàng thì có, nó xảy ra vào một ngày cụ thể và nó trỏ tới chính khách hàng kia.
Ranh giới này quyết định thứ tự nạp dữ liệu lên hệ thống, và tôi đã nói riêng chuyện đó ở bài về chuyển dữ liệu theo đối tượng. Nó cũng quyết định cách chia nhóm quyền, bởi người được tạo đơn hàng chưa chắc đã được sửa danh mục sản phẩm, và chuyện đó thuộc về bài về phân quyền.
Đặc biệt, phần lớn thời gian bạn đọc được ranh giới này ngay trên màn hình mà không cần hỏi ai: mở phân hệ ra, nhìn menu, rồi áp câu hỏi về sự việc và thời điểm vào từng mục.
Nhóm cấu hình hay bị người mới bỏ qua vì nó nằm ở cuối và vì cái tên nghe như chuyện kỹ thuật.
Thực tế thì đây là nhóm quyết định hai nhóm kia trông như thế nào. Bật một tính năng trong cấu hình thì trên màn hình đơn hàng xuất hiện thêm trường, tắt nó đi thì trường biến mất; khai báo một danh mục trong cấu hình thì người dùng mới chọn được giá trị đó khi nhập liệu.
Có khi cả một mục menu cũng phụ thuộc vào cấu hình: trên Odoo 19, menu Leads của CRM chỉ hiện ra khi bạn bật tùy chọn Leads trong Settings của phân hệ, còn chưa bật thì người dùng chỉ thấy pipeline cơ hội.
Do đó khi bạn nhận một yêu cầu và muốn biết hệ thống có đáp ứng được không, chỗ nên mở đầu tiên thường là menu cấu hình của phân hệ liên quan chứ không phải màn hình nghiệp vụ. Rất nhiều thứ trông như phải làm thêm hóa ra chỉ là một ô chưa được tích.
Khung nào cũng có ngoại lệ, và phải nói ra ngoại lệ thì khung mới dùng được.
Ngoại lệ rõ nhất là phân hệ Discuss, nơi trao đổi nội bộ. Trên Odoo 19 thanh menu của nó chỉ có ba mục là Discuss, Channels và Configuration, không có nhóm báo cáo, và thực ra nó cũng không tách bạch dữ liệu chủ với transaction data; chỉ còn lại nhóm cấu hình là khớp khung.
Ngoại lệ thứ hai gặp thường xuyên hơn nhiều, đó là có những mục menu không thuộc nhóm nào cả. Chúng thường là bộ lọc theo trạng thái, chẳng hạn mục To Invoice trong Sales gom các đơn đang chờ xuất hóa đơn, hoặc là nhóm thao tác, chẳng hạn mục Operations trong Inventory gom các loại phiếu điều chuyển. Gặp những mục như vậy thì đừng cố nhét vào bốn nhóm, hãy coi chúng là lối đi tắt mà Odoo dựng sẵn cho công việc hằng ngày.
Ngoại lệ thứ ba là dữ liệu chủ có thể nằm lẫn trong nhóm giao dịch. Trên Odoo 19, cả danh sách Sales Teams lẫn danh sách Customers đều nằm dưới mục Orders của phân hệ Sales. Khi gặp chuyện đó thì bạn dựa vào câu hỏi về sự việc và thời điểm ở trên để tự phân, chứ đừng dựa vào chỗ nó được xếp.
Ngoài ra, số lượng menu bạn nhìn thấy còn phụ thuộc vào phân quyền của chính tài khoản đang đăng nhập, bởi menu được lọc theo nhóm quyền và với menu không gán nhóm thì hệ thống xét tiếp quyền đọc trên đối tượng mà menu đó mở ra.
Đây là nguồn gốc của một tình huống rất hay gặp khi làm việc với khách: bạn báo đã cài xong một phân hệ, khách đăng nhập vào và nói không thấy đâu cả. Trong phần lớn trường hợp thì phân hệ đã ở đó, chỉ là tài khoản của họ chưa được cấp quyền nhìn thấy nó.
Cùng một tập dữ liệu, Odoo cho phép nhìn theo nhiều dạng khác nhau, và mỗi dạng phục vụ một kiểu câu hỏi.
Odoo còn vài dạng xem khác, chẳng hạn dạng bản đồ, nhưng trong các dự án tôi tham gia thì chúng ít khi là thứ người dùng mở hằng ngày, nên năm dạng trên là đủ để bạn đọc một phân hệ mới.
Cần lưu ý rằng dạng xem mặc định của một đối tượng không phải chuyện ngẫu nhiên, và đó chính là chỗ dẫn tới thói quen đáng giá nhất trong bài này.
Mỗi khi thấy Odoo làm một chuyện gì đó theo cách bạn không ngờ tới, hãy dừng lại hỏi vì sao họ thiết kế như vậy, thay vì ghi nhớ nó như một sự thật rời rạc.
Ví dụ tôi vẫn dùng để giải thích thói quen này là chuyện Lead và Cơ hội trong phân hệ CRM. Trên Odoo 19, Lead mở ra ở dạng list, còn Cơ hội thì mở ra ở dạng kanban theo giai đoạn. Nếu chỉ học thao tác thì bạn ghi nhớ hai chuyện đó là hai chuyện riêng lẻ.
Nếu hỏi vì sao thì theo cách tôi hiểu, Lead là thứ chưa được sàng lọc, số lượng lớn, và việc bạn làm với nó là lướt qua rồi loại bớt, đúng thứ mà dạng list phục vụ tốt. Còn Cơ hội thì ít hơn, mỗi cái có vòng đời riêng, và việc bạn làm với nó là đẩy nó đi qua từng giai đoạn, đúng thứ mà dạng kanban phục vụ tốt.
Odoo không viết lời giải thích này ở đâu cả, đó là suy luận của tôi, nhưng nó đủ để bạn tự suy ra thay vì phải nhớ.
Hiểu tới đó rồi thì bạn không cần nhớ nữa. Và quan trọng hơn, khi khách hàng yêu cầu đổi cách hiển thị thì bạn có căn cứ để nói rằng đổi như vậy sẽ mất cái gì, thay vì chỉ làm theo hoặc chỉ từ chối.
Thói quen này cũng là thứ phân biệt người hiểu sản phẩm với người thuộc thao tác, và khoảng cách đó lộ ra rất nhanh trong buổi làm việc đầu tiên với khách.
Cách kiểm tra xem khung này có dùng được hay không là mang nó ra thử, và dưới đây là cách tôi tự làm mỗi khi phải mở một phân hệ lạ.
Chọn một phân hệ bạn chưa từng dùng.
Làm hết bốn bước đó thì bạn chưa thành thạo phân hệ, nhưng bạn đã đủ để ngồi trong một buổi khảo sát về nó mà không bị động.
Còn hai câu hỏi nữa mà bạn phải trả lời trước khi bắt đầu bất kỳ dự án Odoo nào, và cả hai đều không nằm trong hệ thống: khách dùng bản nào, và hệ thống đặt ở đâu.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận