Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
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.
Ở 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
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 đã 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ớ.
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ứ:
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.
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.
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.
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.
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à:
Đặ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ả.
Đ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.
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.
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.
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.
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.
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 đó 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 đã 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 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.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận