---
title: "Studio sau lúc bấm cài: gói license, quyền dùng và bàn giao"
url: "https://bahub.vn/khoa-hoc/erp-cho-ba/he-qua-van-hanh-cua-viec-chon-studio"
author: "Võ Văn Trí"
published: "2026-09-10"
updated: "2026-11-02"
source: "bahub.vn"
license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc."
---

# Studio sau lúc bấm cài: gói license, quyền dùng và bàn giao

> Studio thuộc bản Enterprise, cài lên gói Standard sẽ kích hoạt chuyển gói. Sau đó là license, người được cầm quyền, dấu vết thay đổi và điều kiện nâng cấp.

- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/he-qua-van-hanh-cua-viec-chon-studio
- Tác giả: Võ Văn Trí
- Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md)
- Chương: Tùy biến và phân quyền

Buổi trình bày giải pháp hôm đó diễn ra suôn sẻ. Khách chỉ hỏi thêm đúng một việc là muốn theo dõi ngày bàn giao thiết bị ngay trên đơn bán hàng, và câu trả lời từ phía đội triển khai là chuyện này Studio dựng xong trong mười phút nên không tính vào chi phí phát triển.

Ba tháng sau, khi không ai còn nhắc tới yêu cầu nhỏ đó nữa, kế toán của doanh nghiệp gọi lại hỏi vì sao khoản thuê bao kỳ này lệch so với con số họ đã duyệt trong dự toán.

> Không ai nói sai trong buổi họp, trường kia đúng là dựng xong trong mười phút và Studio đúng là không cần tới lập trình viên. Nhưng thứ bị bỏ sót nằm ở phần sau lúc bấm cài: công cụ đó thuộc bản nào và kéo theo gói thuê bao nào, ai được phép cầm nó, thứ nó tạo ra nằm ở đâu trong hệ thống, và ai chịu trách nhiệm cho nó sau khi dự án kết thúc.

Chuyện nên chọn Studio hay viết code cho một hạng mục thì tôi đã nói ở bài về [ranh giới giữa cấu hình và customize](https://bahub.vn/khoa-hoc/erp-cho-ba/cau-hinh-hay-customize-erp), còn bài này đi vào phần sau đó, tức những gì bạn phải chuẩn bị khi câu trả lời đã là Studio. Toàn bộ phần cơ chế trong bài này tôi mô tả trên Odoo 19, và đây là loại nội dung bạn phải dựng lại trên đúng bản mình đang chạy chứ không nên tin theo trí nhớ.

## Dòng hợp đồng nằm sau nút cài đặt

Vế thứ nhất thì nhiều người đã biết, vế thứ hai mới là vế quyết định.

**Studio là công cụ của bản Enterprise và không có trong bản Community.** Cách kiểm mà bạn tự làm được là tra kho mã nguồn Community của đúng phiên bản khách sẽ chạy, và với Odoo 19 thì module tương ứng không có ở đó. Việc [so sánh hai bản theo hướng hỏi mình sẽ thiếu gì](https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-community-hay-enterprise) là chủ đề của một bài khác.

Vế thứ hai được tài liệu chính thức của Odoo 19 ghi hẳn thành một cảnh báo: **cài Studio lên một database đang ở gói Standard sẽ tự động kích hoạt việc chuyển lên gói Custom**.

Tài liệu mô tả hai cách xử lý khác nhau tùy hình thức hợp đồng. Với hợp đồng theo năm hoặc nhiều năm thì hệ thống sinh ra một đơn nâng gói có hạn ba mươi ngày; còn với hợp đồng theo tháng thì thuê bao tự chuyển sang gói Custom và mức giá mới được áp ngay khi hóa đơn kỳ kế tiếp phát sinh. Trang bảng giá của Odoo cũng nói gọn rằng cài Studio hoặc thêm công ty vào database là tự động chuyển sang gói Custom.

> Do đó câu trả lời quen thuộc rằng Studio làm được nên không tốn chi phí phát triển chỉ đúng ở vế phát triển, còn vế thuê bao thì nằm ngoài tầm nhìn của người đang trả lời.

Trước khi hứa bất cứ điều gì có chữ Studio trong đó, bạn cần **hỏi database này đang ở gói nào và hợp đồng thuê bao tính theo tháng hay theo năm**, bởi hai câu trả lời đó quyết định hệ quả tài chính rơi vào thời điểm nào và dưới hình thức nào.

Cả hai đều là thông tin mà đội sale hoặc chính doanh nghiệp nắm, và vì chính sách giá có thể đổi nên bài này không đưa ra con số nào; bạn tra trang giá chính thức tại thời điểm báo giá.

![Bấm cài Studio là kéo theo một dòng hợp đồng thuê bao mà người trả lời thường không thấy](https://bahub.vn/uploads/2026/11/1793630551936-yjqynj-he-qua-van-hanh-cua-viec-chon-studio-1.webp "Bấm cài Studio là kéo theo một dòng hợp đồng thuê bao mà người trả lời thường không thấy")

## Nơi các thay đổi Studio thật sự nằm

Câu hỏi tiếp theo quyết định cách bạn tổ chức công việc: kéo thả xong một trường thì thứ vừa tạo ra nằm ở đâu.

Tài liệu chính thức của Odoo 19 trả lời rất gọn, rằng mỗi khi bạn tùy biến bằng Studio thì hệ thống thêm vào database một module mới tên là `studio_customization` và gom các tùy biến vào đó. Nghĩa là những gì bạn làm không nằm rải rác trong phần cấu hình như nhiều người vẫn hình dung, mà tồn tại như một module thật, xuất ra được thành file nén bằng chức năng Export trong Studio rồi nhập vào một database khác bằng chức năng Import.

Từ đó suy ra một cách làm việc mà nhiều dự án bỏ lỡ: **dựng tùy biến trên bản thử, xuất ra file, rồi nhập vào bản chạy thật**, thay vì kéo thả lại lần thứ hai trực tiếp trên production trong lúc người dùng vẫn đang nhập liệu. Cách này còn cho bạn một bản lưu của cấu hình tại từng thời điểm, và với một công cụ không giữ lịch sử phiên bản thì mỗi file như vậy là thứ gần với khái niệm phiên bản nhất mà bạn có.

Kèm theo đó là một điều kiện mà tài liệu ghi thành cảnh báo: **database đích phải cùng phiên bản Odoo và phải có sẵn đúng những app và module mà database nguồn có**, bởi Studio không tự khai các module nền làm phần phụ thuộc của module được xuất ra.

## Danh sách người được cầm Studio

**Đây là một quyết định phân quyền, chứ không phải quyết định về công cụ.**

Một người triển khai Odoo lâu năm từng chỉ ra rằng biểu tượng bật Studio chỉ hiện với người dùng có quyền quản trị phần cài đặt, tức trên màn hình người dùng của Odoo 19 là người có vai trò Administrator, và lời khuyên đi kèm là phân quyền dùng Studio cẩn thận, tránh để người không hiểu hệ thống thao tác vào rồi gây lỗi.

Tài liệu chính thức không viết điều kiện này ra, nên bạn nên tự kiểm trên đúng bản của mình. Nhưng nếu đúng như vậy thì vế đáng chú ý nằm ở chỗ nối: **cấp quyền dùng Studio cho ai thì cũng là cấp cho người đó quyền quản trị cài đặt**, nên danh sách này phải được xét cùng mô hình phân quyền của cả dự án. [Ba tầng phân quyền của Odoo](https://bahub.vn/khoa-hoc/erp-cho-ba/phan-quyen-odoo-ba-tang) là chủ đề của một bài riêng trong cùng cụm này.

Lý do không nên mở rộng danh sách nằm ở chính đặc điểm của công cụ. Theo những gì tôi ghi nhận, **Studio không lưu lịch sử phiên bản của phần tùy biến và chỉ hoàn tác được trong phiên đang mở**, hai giới hạn mà tôi đã nói kỹ ở bài về [nguyên tắc 100% code](https://bahub.vn/khoa-hoc/erp-cho-ba/nguyen-tac-100-phan-tram-code). Ngoài ra một vài thao tác để lại dấu rất khó gỡ trên database, chẳng hạn tạo một đối tượng dữ liệu mới, thứ nên được coi là một quyết định thiết kế chứ không phải một thao tác thử cho biết.

**Quy ước tôi đề xuất là giới hạn ở một người trong giai đoạn vận hành.** Lúc đang triển khai thì có thể là hai, một phía đối tác triển khai và một phía doanh nghiệp, nhưng sau khi hệ thống chạy thật thì rút về một, và tên người đang giữ quyền phải được ghi vào tài liệu bàn giao thay vì chỉ nói miệng trong nhóm chat.

Lý do rất thực tế: khi sáu tháng sau có một trường lạ xuất hiện trên form và không ai nhận, một danh sách ngắn như vậy là chỗ duy nhất để bắt đầu lần dấu, còn với danh sách tám người thì việc lần dấu không bao giờ kết thúc.

![Danh sách người cầm Studio càng ngắn thì càng lần được dấu một trường lạ](https://bahub.vn/uploads/2026/11/1793630555464-j4rb9p-he-qua-van-hanh-cua-viec-chon-studio-2.webp "Danh sách người cầm Studio càng ngắn thì càng lần được dấu một trường lạ")

## Cửa sổ đặt tên kỹ thuật

Tên kỹ thuật của một trường là thứ nên đặt đúng ngay lần đầu, và Odoo 19 cho bạn một cửa sổ rất hẹp để làm việc đó.

Người triển khai nói ở trên cho rằng tên kỹ thuật của một trường mới chỉ sửa được trong lúc đang cấu hình trường đó trong Studio, bấm đóng là mất cơ hội. Vế đầu đúng, và tài liệu chính thức còn dặn thêm một chi tiết dễ bỏ qua: **phải bật chế độ nhà phát triển trước khi thêm trường** thì mới thấy và sửa được tên kỹ thuật lúc cấu hình.

Vế sau thì không hẳn, vì sau khi rời Studio bạn vẫn đổi được tên bằng đường Settings, Technical, Fields. Điều kiện bắt buộc là trước đó **phải gỡ trường ra khỏi mọi dạng xem đang dùng nó**, bởi chỉ cần còn một dạng xem tham chiếu tới là hệ thống chặn lại và nói thẳng rằng không thể đổi tên hay xóa những trường vẫn còn nằm trong dạng xem, kèm luôn tên trường và tên dạng xem đang vướng.

Khi đổi thì giữ nguyên tiền tố mà Studio đặt sẵn, chuyện tôi nói kỹ ở bài về nguyên tắc 100% code.

Kèm theo đó là hai giới hạn bạn nên biết trước khi hứa với ai. Hệ thống chỉ cho đổi tên một trường mỗi lần, và nó không cho đổi kiểu dữ liệu, muốn đổi kiểu thì phải xóa trường đi rồi tạo lại.

Riêng các trường chuẩn do Odoo cài sẵn thì không đụng vào được bằng đường này, hệ thống trả lời rằng thuộc tính của trường cơ sở không sửa được theo cách đó và khuyên viết một module tùy chỉnh.

Vì vậy cách đọc đúng vẫn là **coi việc đặt tên ngay từ đầu như một quy tắc**, còn đường sửa sau là phương án cứu chữa có chi phí, bởi gỡ một trường khỏi mọi dạng xem trên một hệ thống đang chạy thì không phải thao tác vô hại.

Đi kèm chuyện đặt tên là một quy ước mà người triển khai này nhấn mạnh: **đặt nhãn bằng tiếng Anh trước rồi mới dịch**, bởi ngôn ngữ gốc của hệ thống là tiếng Anh và tên kỹ thuật được sinh ra từ chính cái nhãn đó.

## Điều kiện để lần nâng cấp còn được bảo hiểm

Đây là phần gần như không bài viết nào về Studio nhắc tới.

Trong mục cam kết dịch vụ nâng cấp, tài liệu Odoo 19 liệt kê ba nhóm được hỗ trợ:

* các ứng dụng tiêu chuẩn
* các tùy chỉnh tạo bằng Studio, kèm đúng hai điều kiện là **Studio vẫn còn được cài và thuê bao tương ứng vẫn còn hiệu lực**
* và các phần phát triển nằm trong một hợp đồng bảo trì tùy chỉnh riêng

Ở chiều ngược lại, tài liệu ghi rõ những module thêm vào do nội bộ hoặc bên thứ ba viết, kể cả do chính đối tác của Odoo viết, mà không có hợp đồng bảo trì thì không nằm trong phạm vi đó.

Hãy đọc lại hai điều kiện ở nhóm thứ hai, vì chúng biến hai việc trông như dọn dẹp thành hai quyết định có hệ quả. **Việc thứ nhất là gỡ Studio khỏi database** sau khi dự án kết thúc vì nghĩ rằng không còn dùng tới. **Việc thứ hai là để thuê bao rơi vào trạng thái không còn hiệu lực** trong giai đoạn doanh nghiệp đang cân nhắc đổi nhà cung cấp.

Cả hai đều được làm với ý định tiết kiệm, và cả hai đều có thể lấy đi phần bảo hiểm cho chính những thay đổi đang chạy hằng ngày.

> Do đó khi bàn giao, phần này nên được nói bằng ngôn ngữ của doanh nghiệp: những tùy chỉnh của anh chị được nhà sản xuất mang qua các lần nâng cấp với điều kiện công cụ này còn nằm trong hệ thống và thuê bao còn hiệu lực, nên đừng gỡ nó và đừng để thuê bao đứt.

Còn chi phí mang vác các phần tùy chỉnh qua nhiều lần nâng cấp thì tôi đã nói riêng ở bài về [nợ kỹ thuật của customization](https://bahub.vn/khoa-hoc/erp-cho-ba/no-ky-thuat-cua-customization).

![Bàn giao bằng lời của doanh nghiệp: đừng gỡ Studio và đừng để thuê bao đứt](https://bahub.vn/uploads/2026/11/1793630558536-2v32rk-he-qua-van-hanh-cua-viec-chon-studio-3.webp "Bàn giao bằng lời của doanh nghiệp: đừng gỡ Studio và đừng để thuê bao đứt")

## Sổ thay đổi thay cho lịch sử phiên bản

Hệ thống không giữ lịch sử tùy chỉnh, nên **cuốn sổ bạn tự ghi chính là lịch sử duy nhất của phần tùy biến**, và đây là chỗ kỷ luật ghi chép đổi thành tiền ở lần nâng cấp sau.

Trong cách làm của tôi, mỗi lần có người mở Studio trên môi trường thật thì phải ghi lại sáu thông tin:

* Ghi ngày thực hiện và tên người thực hiện
* Ghi môi trường đã thao tác
* Ghi đối tượng dữ liệu và dạng xem bị chạm vào
* Ghi tên kỹ thuật của trường hoặc thành phần mới
* Dẫn mã yêu cầu hoặc mã dòng GAP tham chiếu
* Tóm tắt mục đích nghiệp vụ trong một dòng

**Cuốn sổ này phải nằm cùng chỗ với tài liệu dự án chứ không nằm bên trong chính hệ thống**, bởi tình huống bạn cần tới nó nhất là tình huống hệ thống đang có vấn đề. Nó cũng nên được cập nhật ngay tại thời điểm thao tác chứ không dồn tới cuối tuần, vì phần hay bị quên nhất là mục đích nghiệp vụ, và một trường không rõ dùng để làm gì thì ở lần nâng cấp sau sẽ được xử lý theo cách rẻ nhất là bỏ qua.

## Bộ hồ sơ bàn giao

Khi dự án kết thúc, phần tùy biến bằng Studio nên được bàn giao thành **ba thứ cầm được**, thay vì một câu nói rằng hệ thống có tùy chỉnh.

* **Thứ nhất là file nén xuất ra từ Studio** kèm ngày xuất.
* **Thứ hai là cuốn sổ thay đổi** ở mục trên, để người tiếp quản biết vì sao mỗi thứ tồn tại.
* **Thứ ba là danh sách người có quyền dùng Studio**, kèm quy ước rằng mọi thay đổi mới phải được ghi tiếp vào sổ, bởi một quy ước không được bàn giao thì chết cùng lúc với dự án.

Việc phải nói cho doanh nghiệp biết dự án dùng phương thức tùy chỉnh nào thì thuộc bài về nguyên tắc 100% code, còn phần bổ sung ở đây chỉ là hai điều kiện nâng cấp đi kèm, tức Studio còn cài và thuê bao còn hiệu lực.

## Hai bối cảnh mà bộ quy ước này là thừa

Cần nói thẳng rằng không phải dự án nào cũng cần tới mức này.

**Bối cảnh thứ nhất là doanh nghiệp nhỏ tự vận hành**, không có phần viết code nào, và toàn bộ tùy biến chỉ là vài trường cùng vài bộ lọc; khi đó danh sách hai người là thừa vì vốn chỉ có một người biết làm.

**Bối cảnh thứ hai là hệ thống được xác định sẽ thay trong vòng hai năm**, và lúc đó điều kiện về nâng cấp gần như không còn ý nghĩa.

Ngược lại, có những trường hợp còn cần chặt hơn, đặc biệt khi doanh nghiệp có nhiều pháp nhân dùng chung một hệ thống và mỗi pháp nhân có một người quản trị riêng muốn tự sửa giao diện.

Cuối cùng là một giới hạn mà tôi muốn nói rõ. Tài liệu chính thức nói các tùy chỉnh tạo bằng Studio nằm trong phạm vi dịch vụ nâng cấp, nhưng cũng nói phạm vi đó chỉ là chuyển đổi và điều chỉnh kỹ thuật để database tương thích với bản đích, không gồm việc dọn dữ liệu, cấu hình cũ hay đào tạo, và không mô tả chuyện gì xảy ra với từng thành phần khi cấu trúc của bản mới đã đổi.

Vì vậy **tôi không khẳng định gì về mức độ nguyên vẹn của tùy biến sau nâng cấp**.

Trong bộ công cụ mà Studio thường được dùng cùng, phần còn thiếu là những thứ chạy tự động phía sau một nút bấm hoặc một thay đổi trạng thái, và đó là chủ đề của bài về [Automation Action](https://bahub.vn/khoa-hoc/erp-cho-ba/automation-action-odoo-gioi-han).

---

Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/he-qua-van-hanh-cua-viec-chon-studio — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.