Master data và Transaction data: hai loại dữ liệu quyết định thứ tự triển khai

Hai loại dữ liệu nhìn từ hệ quả

Cách phân biệt quen thuộc là dựa vào hình thức, tức master data thì đứng yên còn transaction data thì phát sinh hằng ngày.

master data là những bản ghi tồn tại độc lập, không mô tả một sự việc xảy ra vào thời điểm nào, và được rất nhiều bản ghi khác trỏ tới. transaction data thì ghi lại một sự việc đã xảy ra, luôn gắn với một thời điểm, và luôn trỏ ngược về dữ liệu chủ.

Điểm mấu chốt là quan hệ này chỉ có một chiều. Đơn hàng biết khách hàng của nó là ai, còn khách hàng thì không cần biết mình có bao nhiêu đơn hàng để tồn tại, nghĩa là bạn tạo được một khách hàng trên hệ thống trống rỗng trong khi bạn không tạo được một đơn hàng cho khách hàng chưa tồn tại.

Bên cạnh hai loại trên còn một lớp thứ ba hay bị bỏ qua là dữ liệu cấu hình, tức những thứ phải khai báo hoặc bật lên thì hai loại kia mới chạy được, chẳng hạn kho, loại phiếu, sổ nhật ký. Ranh giới này đọc được ngay từ cấu trúc menu mỗi phân hệ Odoo, và tôi đã nói riêng ở bài về khung bốn nhóm menu.

Những gì thường nằm trong nhóm dữ liệu chủ

Gần như dự án Odoo nào cũng phải dựng lại đúng những đối tượng dưới đây, và đây là điểm bắt đầu chứ không phải danh sách đóng. Nhóm bán hàng và mua hàng gồm liên hệ, tức danh mục dùng chung cho cả khách hàng lẫn nhà cung cấp; sản phẩm; danh mục sản phẩm dạng cây; đơn vị tính cùng bộ quy đổi; bảng giá bán và bảng giá nhà cung cấp. Nhóm kho gồm kho, vị trí kho và tuyến vận hành. Nhóm kế toán gồm hệ thống tài khoản, thuế suất, điều khoản thanh toán, sổ nhật ký. Nhóm nhân sự gồm nhân viên, phòng ban, chức danh, lịch làm việc. Xuyên suốt mọi phân hệ là người dùng và nhóm quyền.

Ranh giới không phải lúc nào cũng gọn, và bảng giá nhà cung cấp là ví dụ nằm giữa vì nó có ngày hiệu lực giống transaction data.

Thứ tự triển khai suy ra từ hướng tham chiếu

Vì transaction data trỏ tới master data, còn master data thì phụ thuộc vào dữ liệu cấu hình, nên thứ tự làm việc của cả dự án bị ép cứng thành cấu hình trước, master data giữa, transaction data sau, và đây là điều kiện để bước sau chạy được chứ không phải một khuyến nghị cho gọn gàng.

Bên trong riêng nhóm master data thì lại có một thứ tự nữa, bởi các đối tượng ở đây cũng trỏ lẫn nhau: sản phẩm trỏ tới danh mục và trỏ tới đơn vị tính nên hai thứ đó phải xong trước; danh mục dạng cây thì danh mục cha có trước danh mục con; đơn vị tính thì đơn vị tham chiếu có trước các đơn vị quy đổi theo nó.

Hồi mới đi làm tôi gặp bài toán này ở một chuỗi bán lẻ dược phẩm, nơi cùng một loại thuốc được mua theo thùng, nhập kho theo hộp, bán ra theo vỉ và theo viên, nên bạn không khai thẳng được quan hệ giữa thùng và vỉ mà phải đi qua hộp ở giữa.

Muốn tự tìm thứ tự cho dự án của mình, bạn mở màn hình tạo mới của từng đối tượng, dò xem những trường nào đang trỏ sang đối tượng khác, và đối tượng nào được trỏ tới thì phải lên trước. Còn cơ chế nạp dữ liệu và bước đối soát thì là chủ đề riêng của bài về chuyển dữ liệu theo đối tượng.

Làm sạch dữ liệu chủ và người chốt danh sách

Dữ liệu chủ sai không nằm yên một chỗ, bởi mỗi bản ghi sai sẽ được hàng trăm chứng từ trỏ tới trong vài tháng đầu, và tới lúc đó thì bạn không còn sửa một dòng mà đang sửa một mạng lưới.

Bốn thứ hay sai nhất là bản ghi trùng, cách đặt tên, mã nội bộ, và những trường bị để trống vì lúc nhập không ai biết điền gì. Hai khách hàng cùng tên trong danh mục liên hệ là ví dụ điển hình của loại thứ nhất, và nó nguy hiểm ở chỗ hệ thống không coi đó là lỗi, người nhập liệu chọn đại một trong hai, rồi công nợ của một pháp nhân bị xẻ làm đôi cho tới kỳ đối chiếu.

Về việc ai chốt, danh sách master data phải do phía doanh nghiệp ký nhận, vì việc gộp hay tách hai bản ghi là một quyết định nghiệp vụ chứ không phải một thao tác dữ liệu. Cũng cần nói thẳng một giới hạn: không có công cụ nào làm sạch hộ bạn ở mức nghiệp vụ, và ứng dụng dò trùng của Odoo thì thuộc nhóm phải trả phí.

Ràng buộc xóa và cơ chế lưu trữ

Quay lại tình huống mở bài. Khi bạn thử xóa một bản ghi dữ liệu chủ đã được một chứng từ khác nhắc tới, hệ thống chặn lại và hiện một thông báo nói rằng có mô hình khác đang dùng bản ghi bạn định xóa, kèm theo tên đúng của chứng từ đang giữ nó và tên trường tạo ra ràng buộc, rồi kết lại bằng một câu gợi ý bạn lưu trữ bản ghi thay vì xóa. Đây là ràng buộc khóa ngoại ở tầng cơ sở dữ liệu chứ không phải quy tắc nghiệp vụ do người triển khai cấu hình, nên không ai vượt qua nó bằng cách cấp thêm quyền, và bạn cũng đừng trông chờ vào chuyện chứng từ mới ở trạng thái nháp thì sẽ dễ xóa hơn, bởi ràng buộc này không hề nhìn vào trạng thái, một đơn bán ở trạng thái nháp chặn việc xóa sản phẩm y hệt một đơn đã xác nhận, không khác một chữ nào trong thông báo.

Có một ngoại lệ ngược với trực giác của phần lớn mọi người, đó là không phải mọi tham chiếu đều chặn xóa, nhưng thứ quyết định lại không phải chuyện trường tham chiếu ấy có bắt buộc hay không, mà là cách trường đó được khai báo hành vi cho lúc bản ghi đích bị xóa: dòng đơn bán hàng giữ sản phẩm bằng một trường không hề bắt buộc mà vẫn chặn tuyệt đối, trong khi phiếu kho giữ liên hệ bằng một trường cũng không bắt buộc nhưng lại cho xóa rồi lặng lẽ để lại ô trống trên toàn bộ phiếu cũ. Nghĩa là bạn đừng suy ra hành vi xóa từ trường dữ liệu bắt buộc trên màn hình. Nhánh làm rỗng mới là kiểu mất dữ liệu khó phát hiện nhất, vì nó không báo gì cả.

Lưu trữ, tức archive, là cơ chế được dựng ra đúng cho tình huống này. Về bản chất nó chỉ tắt một trường đánh dấu bản ghi còn hoạt động hay không, và hệ quả là bản ghi biến mất khỏi mọi danh sách cùng mọi ô chọn lúc nhập liệu, trong khi nó vẫn nằm nguyên trong cơ sở dữ liệu nên chứng từ cũ vẫn trỏ tới được và báo cáo lịch sử vẫn đúng. Đổi lại, người dùng phải biết bật bộ lọc mới thấy lại bản ghi đã lưu trữ, và đây là chỗ nên dạy trong buổi đào tạo vì kiểu gì cũng có người lưu trữ nhầm rồi tưởng mất dữ liệu.

Từ đó suy ra một thói quen nên tập từ dự án đầu tiên là gặp dữ liệu chủ rác thì lưu trữ ngay.

Ảnh hưởng ngược khi sửa master data

Câu khách hay hỏi nhất ở nhóm này là đổi thông tin trên một bản ghi cũ thì có làm sai số liệu quá khứ không, và câu trả lời phải chia làm hai vế.

Vế thứ nhất là những dữ liệu được record khi chứng từ được tạo. Trên dòng của một đơn hàng, phần mô tả và đơn giá được tính ra lúc bạn chọn sản phẩm rồi lưu luôn xuống dòng, nên về sau bạn đổi tên sản phẩm hay đổi giá bán trong danh mục thì các đơn cũ vẫn giữ nguyên mô tả và đơn giá tại thời điểm chốt đơn.

Vế thứ hai là những dữ liệu onchange. Tên hiển thị của khách hàng trên đơn cũ, tên sản phẩm ở ô tham chiếu, địa chỉ lấy từ hồ sơ liên hệ, tất cả đều được đọc lại từ bản ghi gốc mỗi lần bạn mở chứng từ ra, nên đổi tên trong danh mục là toàn bộ chứng từ quá khứ đổi theo.

Trường hợp mạnh nhất của chuyện ảnh hưởng ngược là đổi đơn vị tính của sản phẩm đã phát sinh phiếu kho. Nếu mọi dòng dịch chuyển cũ đều đang dùng đúng đơn vị gốc đang đặt trên sản phẩm, hệ thống cho bạn đổi, cảnh báo trước rằng nó áp quy đổi một đơn vị cũ bằng một đơn vị mới, rồi ghi đè tên đơn vị lên chính các dòng lịch sử - tức là con số số lượng giữ nguyên còn cái tên bên cạnh thì đổi, và một phiếu nhập mười thùng hôm qua sẽ đọc thành mười hộp vào hôm nay. Ngược lại, chỉ cần có một dòng dùng đơn vị khác đơn vị gốc là hệ thống chặn hẳn, báo rằng đã có đơn vị khác được dùng cho sản phẩm này nên không thể đổi, rồi chỉ đường là hãy lưu trữ sản phẩm cũ và tạo một sản phẩm mới.

Checklist trước khi chốt một danh mục master data

Trước khi cho phép đưa master data lên hệ thống, hãy chạy thực hiện các việc sau.

• Rà bản ghi trùng theo tên, theo mã số thuế và theo mã nội bộ
• Thống nhất quy tắc đặt tên và ghi quy tắc đó vào tài liệu
• Kiểm những đối tượng mà danh mục này trỏ tới đã có đủ trên hệ thống chưa
• Lưu trữ các bản ghi thử nghiệm còn sót từ giai đoạn dựng hệ thống
• Thử tạo một chứng từ nháp có dùng danh mục này rồi hủy đi

Việc cuối nghe thừa nhưng là bước phát hiện nhanh nhất các trường bắt buộc bạn chưa khai báo, bởi thứ gì bắt buộc lúc tạo bản ghi bằng tay thì cũng bắt buộc lúc nạp.

Việc còn lại là đưa hai loại dữ liệu này lên hệ thống thật theo đúng thứ tự vừa tìm ra, và cách làm chuyện đó theo từng đối tượng là một bài riêng.