--- title: "Contact, Customer, Vendor: một bảng ba cách nhìn" url: "https://bahub.vn/khoa-hoc/erp-cho-ba/contact-customer-vendor-odoo" 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." --- # Contact, Customer, Vendor: một bảng ba cách nhìn > Cấu trúc danh mục liên hệ trong Odoo: công ty và cá nhân, contact con và ba loại địa chỉ, một đối tác đứng cả hai đầu công nợ, và hệ quả gộp nhầm pháp nhân. - Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/contact-customer-vendor-odoo - 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: Phân hệ Odoo Ở bước chuẩn bị danh mục, gần như dự án nào cũng có người tin rằng hai dòng liên hệ có tên gần giống nhau là một khách hàng bị nhập trùng, và gộp lại thì dữ liệu sạch hơn. > Hiểu lầm này sai ở chỗ nó lấy cái tên làm khóa nhận dạng, trong khi thứ quyết định một dòng trong danh mục đối tác là pháp nhân đứng sau nó. **Hai đơn vị có hai mã số thuế riêng, tự ký hợp đồng riêng và tự thanh toán riêng thì là hai đối tác**, kể cả khi tên chỉ khác nhau ở phần đuôi. Cái giá của việc gộp nhầm cũng không dừng ở chỗ kế toán trưởng không lấy được bảng công nợ tách riêng. Phiếu giao hàng in ra một địa chỉ duy nhất nên tài xế mang hàng của đơn vị này tới kho của đơn vị kia, còn hóa đơn thì mang một mã số thuế nên bên còn lại từ chối nhận, và tới lúc đó chứng từ đã phát sinh, sửa lại không còn là chuyện sửa danh mục nữa. Cái hỏng ở đây không phải chuyện nhập liệu, mà là **một quyết định thiết kế danh mục đã bị bỏ qua từ giai đoạn khảo sát**. Việc các nhãn Khách hàng, Nhà cung cấp, Liên hệ và Đối tác cùng trỏ về một danh mục duy nhất thì bài về [ERP nhìn từ người đi triển khai](https://bahub.vn/khoa-hoc/erp-cho-ba/erp-la-gi) đã nói rồi; phần bạn cần ở đây nằm sâu hơn một tầng, trong chính cấu trúc bên trong danh mục đó. 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ớ. ## Hai trục quyết định một bản ghi đối tác Mỗi bản ghi trong danh mục liên hệ được định vị bằng hai trục độc lập, và phần lớn hiểu lầm bạn gặp trong dự án đều là hệ quả của việc trộn hai trục đó làm một. **Trục thứ nhất trả lời câu hỏi bản ghi này là một tổ chức hay một con người.** Trên màn hình nó hiện thành cặp lựa chọn Người và Công ty ngay đầu form, còn bên dưới chỉ là một ô đúng sai đánh dấu bản ghi có phải công ty hay không; bản thân cặp lựa chọn kia chỉ là lớp giao diện, Odoo cũng tự dặn không dùng nó trong logic nghiệp vụ. Lựa chọn ở trục này kéo theo ba thứ: * gợi ý ở ô nhập tên * quy tắc ai được làm cha của ai * và cách hệ thống truy ra pháp nhân ở tầng kế toán. **Trục thứ hai trả lời câu hỏi đối tác này đứng ở vai nào.** Cần lưu ý rằng trên Odoo 19 hai vai này không được đánh dấu bằng ô tích như ở những bản rất cũ. Thay vào đó hệ thống giữ hai con số đếm là xếp hạng khách hàng và xếp hạng nhà cung cấp: tạo bản ghi từ menu Khách hàng thì xếp hạng khách bằng một, tạo từ menu Nhà cung cấp thì ngược lại, và mỗi lần một hóa đơn bán hay hóa đơn mua của đối tác được vào sổ thì con số tương ứng tăng lên. Hai con số này dùng để đẩy những đối tác hay giao dịch lên đầu danh sách gợi ý khi chọn đối tác trên chứng từ. Do đó **hai menu kia là hai lát cắt có bộ lọc và thứ tự khác nhau trên cùng một bảng, không phải hai danh mục**. Từ đó suy ra câu trả lời cho câu hỏi khách hay hỏi nhất ở nhóm này: một đối tác vừa bán cho mình vừa mua của mình thì **bạn tạo đúng một bản ghi**, và không phải làm thêm thao tác nào để mở vai thứ hai. ![Vừa là khách vừa là nhà cung cấp thì vẫn chỉ một bản ghi](https://bahub.vn/uploads/2026/11/1793631246389-mlyju5-contact-customer-vendor-odoo-1.webp "Vừa là khách vừa là nhà cung cấp thì vẫn chỉ một bản ghi") ## Công ty và người liên hệ đứng dưới nó Một công ty trong danh mục hiếm khi đứng một mình, bởi bên dưới nó còn nhân sự đầu mối, kho nhận hàng, bộ phận kế toán nhận hóa đơn. Odoo dựng quan hệ này bằng một trường trỏ ngược lên công ty cha, trên form của một liên hệ cá nhân nó hiện là ô Công ty. Trên nền quan hệ đó, hệ thống tính ra **pháp nhân kinh doanh** của một bản ghi, và bạn phải nắm khái niệm này để đọc được số liệu kế toán. Quy tắc rất gọn: bản ghi là công ty hoặc không có cha thì pháp nhân kinh doanh chính là nó; ngược lại thì hệ thống leo lên lấy pháp nhân kinh doanh của cha, cho tới khi chạm một công ty. Nghĩa là **mọi contact con của một công ty đều quy về đúng một pháp nhân**, và đây là chỗ quyết định câu chuyện công nợ ở phần sau của bài. Đi kèm quan hệ cha con là hai hành vi đồng bộ mà hầu như không ai được cảnh báo trước. **Thứ nhất, contact con thuộc loại Liên hệ dùng chung địa chỉ với công ty cha theo cả hai chiều**: sửa địa chỉ trên một contact con loại này thì hệ thống ghi ngược lên công ty cha, rồi từ đó đổ xuống toàn bộ contact con cùng loại còn lại, và người sửa không hề biết mình vừa đổi địa chỉ của cả nhà. **Thứ hai, khi một công ty đang để trống địa chỉ được gắn contact con đầu tiên**, và contact đó có địa chỉ, thì hệ thống hiểu đó là địa chỉ công ty và tự chép lên bản ghi cha. Ngoài ra còn một ràng buộc đáng ghi vào tài liệu là hệ thống chặn phân cấp vòng, tức hai bản ghi không thể lần lượt làm cha của nhau. ## Ba loại địa chỉ con và chỗ chúng được dùng Mỗi contact con mang thêm một trường kiểu địa chỉ, và trên Odoo 19 trường này có đúng bốn giá trị là Contact, Invoice, Delivery và Other, giao diện tiếng Việt hiện là Liên hệ, Hóa đơn, Giao hàng và Khác. Bạn chọn kiểu địa chỉ ngay lúc thêm một dòng trong tab Liên hệ của công ty, và nó chỉ có nghĩa khi bản ghi đã có công ty cha. Chỗ ba loại địa chỉ con thật sự được dùng nằm trên chứng từ. Khi bạn chọn khách hàng trên một đơn bán, hệ thống tìm trong nhánh của khách đó một bản ghi loại Hóa đơn và một bản ghi loại Giao hàng để điền vào hai ô địa chỉ xuất hóa đơn và địa chỉ giao hàng; **không tìm thấy thì nó lùi về chính khách hàng đang chọn**. Nếu người dùng chọn một người liên hệ thay vì chọn công ty, hệ thống còn leo ngược lên công ty cha để tìm tiếp. Cơ chế lùi dần này là lý do nhiều dự án chạy êm suốt giai đoạn demo rồi vỡ ở dữ liệu thật: lúc demo mỗi khách chỉ có một địa chỉ nên ô nào cũng điền đúng. Đây cũng là chỗ bạn trả lời được yêu cầu quen thuộc kiểu khách ký hợp đồng ở văn phòng nhưng nhận hàng về mười cửa hàng, mà không phải tạo mười khách hàng. Ngược lại, khi khách chỉ có một địa chỉ thì đừng dựng contact con cho đủ bộ, bởi mỗi tầng thêm vào là một chỗ nữa để người dùng chọn nhầm và một chỗ nữa phải dạy trong buổi đào tạo. ![Ký ở văn phòng, giao về mười cửa hàng mà không phải tạo mười khách hàng](https://bahub.vn/uploads/2026/11/1793631246896-0zvzrs-contact-customer-vendor-odoo-2.webp "Ký ở văn phòng, giao về mười cửa hàng mà không phải tạo mười khách hàng") ## Một đối tác đứng cả hai đầu công nợ Khi doanh nghiệp vừa bán cho một đối tác vừa mua của chính đối tác đó, thứ bạn phải giải thích cho kế toán là hai số dư nằm ở đâu và chúng có tự triệt tiêu hay không. Hệ thống tính **hai con số hoàn toàn tách rời** trên cùng một bản ghi. Tổng phải thu cộng từ những dòng bút toán đã vào sổ và chưa đối trừ thuộc nhóm tài khoản phải thu, tổng phải trả cộng từ những dòng thuộc nhóm tài khoản phải trả, và không có phép trừ nào giữa hai con số đó. Nghĩa là một đối tác vừa nợ bạn một khoản vừa được bạn nợ một khoản, và cả hai cùng hiện trên hồ sơ của họ. Lấy ví dụ một nhà cung cấp bao bì đồng thời mua lại hàng lỗi của bạn: hồ sơ của họ hiện tổng phải thu ba trăm triệu và tổng phải trả hai trăm triệu, và **hệ thống không tự rút thành một trăm triệu**. Từ đó phát sinh một câu hỏi bạn phải mang ra buổi khảo sát chứ không được tự quyết: doanh nghiệp có nghiệp vụ bù trừ công nợ hai chiều hay không, nếu có thì ai đề nghị, chứng từ nào ghi nhận và ai duyệt. > Đây là câu hỏi kế toán chứ không phải câu hỏi cấu hình, và trả lời hộ khách là cách nhanh nhất để nhận lại một change request ở giai đoạn UAT. Ngược lại, để đối tác đó tồn tại thành hai bản ghi thì không bên nào nhìn thấy vị thế hai chiều. ## Các trường kế toán treo trên đối tác Nhóm trường tiếp theo hay bị bỏ qua vì nằm ở tab phía sau, trong khi chúng quyết định phần lớn những gì tự đổ xuống chứng từ. Trên một bản ghi đối tác, bốn trường đáng nhớ nhất là: * tài khoản phải thu mặc định * tài khoản phải trả mặc định * điều khoản thanh toán * và hạn mức tín dụng. Đặc biệt cần chú ý **điều khoản thanh toán phía bán và phía mua là hai trường tách biệt**, nên một đối tác đứng cả hai đầu vẫn khai được hai kỳ hạn khác nhau. Ba đặc điểm của nhóm trường này đáng ghi vào tài liệu đặc tả. * **Đầu tiên, chúng phụ thuộc vào công ty đang làm việc**, nên trong một database nhiều pháp nhân thì cùng một đối tác mang hai bộ giá trị ứng với hai công ty. * **Tiếp theo, chúng do pháp nhân kinh doanh nắm giữ và được đồng bộ từ cha xuống toàn bộ nhánh con**, nên khai điều khoản thanh toán riêng cho một contact con là việc vô ích. * **Cuối cùng, và đây là điểm nặng nhất, bút toán kế toán luôn được ghi cho pháp nhân kinh doanh** chứ không ghi cho contact con phát sinh chứng từ. Điều đó chính là câu trả lời cho yêu cầu theo dõi công nợ theo chi nhánh. Dựng chi nhánh thành contact con của công ty mẹ thì công nợ dồn hết về công ty mẹ; muốn mỗi chi nhánh có số dư riêng thì chi nhánh phải là một bản ghi độc lập, và lúc đó bạn mất khả năng nhìn tổng theo nhóm bằng cấu trúc cha con. > Hai lựa chọn đều có giá của nó, và người phải chọn là phía doanh nghiệp chứ không phải bạn. ![Chi nhánh là contact con hay bản ghi riêng: mỗi cách đổi lấy một kiểu nhìn công nợ](https://bahub.vn/uploads/2026/11/1793631248859-7dpkb7-contact-customer-vendor-odoo-3.webp "Chi nhánh là contact con hay bản ghi riêng: mỗi cách đổi lấy một kiểu nhìn công nợ") Thêm một ràng buộc nên biết trước khi hứa với khách: đối tác đã có hóa đơn vào sổ thì mã số thuế trên bản ghi không sửa được nữa, và cũng không gắn được một đối tác đã phát sinh bút toán vào làm contact con của một đối tác mang mã số thuế khác. ## Những câu hỏi phải hỏi trước khi dựng danh mục Bộ câu hỏi dưới đây tôi đặt ra ngay trong buổi khảo sát nhóm bán hàng và nhóm kế toán, vì trả lời muộn thì cái giá là dữ liệu chứ không phải công cấu hình. * **Nhóm thứ nhất là phân cấp**: các chi nhánh của khách có mã số thuế riêng hay dùng chung, có tự ký hợp đồng và tự thanh toán hay không, và doanh nghiệp muốn nhìn công nợ ở cấp tổng công ty hay cấp chi nhánh. * **Nhóm thứ hai là địa chỉ**: hóa đơn xuất cho pháp nhân nào, hàng giao tới đâu, hai thứ đó có tách nhau không. * **Nhóm thứ ba là quyền**: ai được tạo đối tác mới, ai được sửa thông tin đã có, ai được chạm vào nhóm trường kế toán, bởi mở toang thì ba tháng sau danh mục đầy bản ghi rác; [ba tầng phân quyền](https://bahub.vn/khoa-hoc/erp-cho-ba/phan-quyen-odoo-ba-tang) là chủ đề của một bài riêng. * **Nhóm thứ tư là trùng lặp**: ai chịu trách nhiệm phát hiện, ai đủ thẩm quyền quyết định gộp, và gộp thì giữ lại bản nào. Sau khi có câu trả lời, hãy tự chạy qua năm thao tác dưới đây trên hệ thống dự án trước khi viết tài liệu. * Tạo một công ty, gắn vào đó một địa chỉ giao hàng và một địa chỉ xuất hóa đơn * Lập một đơn bán cho công ty đó rồi kiểm hai ô địa chỉ hệ thống tự điền * Sửa địa chỉ trên một contact con loại Liên hệ rồi mở lại công ty cha xem có đổi theo * Vào sổ một hóa đơn cho contact con rồi mở công ty cha xem công nợ nằm ở đâu * Tạo hai bản ghi cùng mã số thuế rồi xem hệ thống cảnh báo hay chặn Thao tác cuối đáng nhớ nhất, bởi kết quả của nó thường trái với kỳ vọng của khách. ## Hệ quả của việc gộp nhầm và tách nhầm Quay lại tình huống mở bài. Khi hai pháp nhân bị gộp làm một, cái mất không phải một dòng danh mục mà là mã số thuế thứ hai, địa chỉ thứ hai, hạn mức thứ hai, và toàn bộ chứng từ đã phát sinh đều trỏ về một pháp nhân. Sửa lại sau go-live nghĩa là tách bản ghi rồi còn phải xử lý các bút toán đã đứng tên pháp nhân cũ, và phần [chuyển dữ liệu](https://bahub.vn/khoa-hoc/erp-cho-ba/data-migration-erp) đó có bài riêng. Đặc biệt cần lưu ý rằng **chức năng gộp liên hệ chuyển hết tham chiếu về bản ghi đích rồi xóa hẳn bản ghi nguồn**, nên không có nút hoàn tác và cũng không còn bản ghi lưu trữ nào để mở lại. Ràng buộc đáng nói trước với khách là mỗi lần gộp tối đa ba bản ghi, kể cả với tài khoản quản trị. Chiều ngược lại thì cái giá là hạn mức tín dụng và điều khoản thanh toán bị xẻ theo từng bản ghi, còn chuyện công nợ của một pháp nhân bị chia đôi thì bài về [master data và transaction data](https://bahub.vn/khoa-hoc/erp-cho-ba/master-data-va-transaction-data) đã nói. Ở đây có một giới hạn tôi phải nói thẳng, thay vì để bạn tin hệ thống sẽ đỡ hộ. **Cảnh báo trùng của Odoo chỉ so theo mã số thuế và mã doanh nghiệp**, chỉ áp cho bản ghi không có công ty cha, và nó hiện ra dưới dạng một dải cảnh báo trên form chứ không chặn lưu; trùng theo tên hay theo số điện thoại thì nó không nói gì cả. Công cụ dò trùng theo quy tắc nằm trong ứng dụng Data Cleaning và chỉ có ở bản Enterprise; [ranh giới giữa hai bản](https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-community-hay-enterprise) là chủ đề của một bài khác. Việc làm sạch danh mục trước khi nạp cũng đã có bài riêng; ở đây chỉ cần nhớ **phía doanh nghiệp phải ký nhận danh sách đối tác trước khi có chứng từ đầu tiên đè lên**. Khi danh mục đối tác đã đứng vững, phần việc kế tiếp là dựng đường đi của một yêu cầu mua từ lúc phát sinh cho tới lúc có người đủ thẩm quyền ký duyệt. --- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/contact-customer-vendor-odoo — Đượ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.