Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Đi theo một đơn hàng từ lúc khách hỏi giá tới lúc tiền về, xem ở mỗi chặng hệ thống tạo ra dữ liệu gì, trạng thái nào đổi, ai bị ảnh hưởng và chỗ nào hay đứt.
Trong buổi đào tạo cho nhóm kho của một doanh nghiệp phân phối, câu hỏi được hỏi nhiều nhất là đơn hàng bên bán hàng vừa chốt nằm ở đâu, bởi người nhân viên kho mở phân hệ Bán hàng lên thì thấy màn hình trống trơn.
Người hỏi không sai ở chỗ nào. Chỉ là tài khoản nhân viên kho thường không được cấp quyền vào đơn bán hàng, và thứ họ cần tìm cũng không phải đơn hàng mà là phiếu giao hàng do đơn đó sinh ra, nằm bên phân hệ Kho và tra được theo mã đơn ở trường chứng từ gốc.
Câu hỏi đó nghe như chuyện thao tác, nhưng nó là dấu hiệu của một khoảng trống lớn hơn: trong ERP, thao tác của bộ phận này biến thành việc phải làm của bộ phận khác thông qua dữ liệu chứ không thông qua một cuộc gọi. Không thấy dữ liệu ở chỗ quen nhìn thì người dùng đứng lại chờ, và người mới làm nghề cũng vướng đúng chỗ này, vì tài liệu học mô tả từng phân hệ tách rời.
Cách lấp nó nhanh nhất là đi theo một đơn hàng từ lúc khách hỏi giá tới lúc tiền về, dừng ở mỗi chặng và hỏi ba câu: chặng này sinh ra dữ liệu gì, trạng thái nào vừa đổi, và ai bị ảnh hưởng. Mọi mô tả hành vi hệ thống trong bài dựa trên Odoo 19.
Một đơn hàng đi qua năm chặng là báo giá, xác nhận đơn, giao hàng, lập hóa đơn và thu tiền, mà ranh giới giữa các chặng chính là ranh giới giữa các bộ phận.
Mỗi chặng sinh ra một chứng từ mới, và chứng từ đó không được gõ lại từ đầu mà kế thừa phần lớn nội dung từ chứng từ trước rồi mới bổ sung nội dung/thông tin do bộ phận phụ trách nhập vào. Sợi dây nối chúng lại là trường chứng từ gốc, thứ cho phép bạn đứng ở bất kỳ mắt xích nào cũng lần ngược về được mắt xích đầu tiên. Luận điểm ERP mạnh vì các phân hệ dùng chung một cơ sở dữ liệu thì tôi đã nói riêng ở bài về ERP là gì; ở đây bạn cần thấy nó vận hành ra sao.
Khi nhân viên bán hàng tạo báo giá và chọn khách hàng, hệ thống lấy bảng giá cùng nhân viên phụ trách đã khai trên hồ sơ khách, đồng thời lấy địa chỉ giao hàng và địa chỉ xuất hóa đơn từ các liên hệ con của công ty đó. Chọn sản phẩm thì hệ thống lấy đơn giá theo bảng giá vừa gán, lấy thuế và mô tả từ hồ sơ sản phẩm. Đây là chiều chảy dễ bị bỏ qua nhất, bởi master data chảy xuống chứng từ chứ không phải người dùng nhập tay từng lần.
Dữ liệu tạo ra ở chặng này gồm một đơn hàng ở trạng thái Báo giá và các dòng chi tiết. Trạng thái đổi hai lần trước khi rời chặng: bấm nút gửi email thì đơn chuyển sang Báo giá đã gửi, còn khi khách mở đường dẫn portal và ký thì đơn tự chuyển sang Đơn bán hàng mà người bán hàng không cần thao tác thêm.
Ai bị ảnh hưởng ở đây thì gần như chưa ai, ngoài người bán hàng và quản lý của họ. Đó là lý do báo giá là chỗ duy nhất trong cả dòng chảy mà bạn còn sửa thoải mái được, còn đoạn phễu phía trước thì thuộc phân hệ CRM và là một dòng chảy riêng tôi sẽ nói ở bài khác.
Nút xác nhận đơn là nơi mà tính chất hệ thống lộ ra rõ nhất, vì một cú bấm của một người mà ba bộ phận khác có việc.
Trạng thái đơn chuyển sang Đơn bán hàng, hệ thống chạy quy tắc kho và sinh phiếu giao hàng cho các dòng hàng lưu kho. Phiếu này không phải bản sao rỗng: chứng từ gốc của nó là mã đơn hàng, hạn chót giao hàng lấy từ ngày giao dự kiến trên đơn, đối tác nhận hàng lấy từ địa chỉ giao hàng, kho xuất lấy từ kho đã chọn. Từ lúc đó, mỗi dòng hàng có thêm hai con số chạy theo nó suốt phần đời còn lại là số lượng hàng đã giao và số lượng hàng đã xuất hóa đơn.
Người chịu ảnh hưởng đầu tiên là nhân viên kho vì họ vừa có thêm một phiếu phải xử lý, người thứ hai là kế toán vì đơn đã xác nhận là cơ sở lập hóa đơn. Người thứ ba là bất kỳ ai đang nhìn báo cáo doanh số hoặc số lượng khả dụng của mặt hàng đó, bởi con số họ thấy vừa thay đổi mà không ai báo.
Cần lưu ý rằng đơn đã xác nhận vẫn sửa được, nhưng lúc đó bạn đang sửa một thứ mà các chứng từ phía sau đã tham chiếu tới, nên ai được sửa và sửa trong trường hợp nào là câu hỏi cần phải hỏi khách ở giai đoạn khảo sát chứ không phải phát hiện lúc kiểm thử.
Nhân viên kho mở phiếu, đối chiếu hàng thực tế, rồi nhập số thực giao vào cột số lượng. Cột nhu cầu bên cạnh là trường chỉ được kế thừa từ đơn hàng, và đây là chi tiết bạn phải ghi rõ khi viết tài liệu cho lập trình viên cũng như khi soạn kịch bản kiểm thử.
Nếu số thực giao ít hơn nhu cầu thì hệ thống sẽ hỏi có tạo phiếu bổ sung cho phần thiếu hay không, và hai lựa chọn để lại hai vết dữ liệu khác nhau. Nếu chọn tạo thì đơn hàng sẽ còn một phiếu đang chờ, người đọc hiểu rằng phần còn lại sẽ được giao tiếp; Nếu chọn không tạo thì đơn chỉ có một phiếu đã hoàn thành với số lượng ít hơn nhu cầu, và phần thiếu coi như không bao giờ được giao nữa. Nên nhớ rằng quyết định bấm nút nào không thuộc về kho mà thuộc về phương án xử lý mà bạn đã thỏa thuận với khách khi triển khai.
Sau khi phiếu được xác nhận thì số lượng đã giao trên từng dòng đơn tăng lên, tồn kho giảm xuống, và lịch sử dịch chuyển của mặt hàng có thêm một dòng. Ở phân hệ Kho thì mọi biến động đều là chuyện chuyển hàng giữa hai vị trí chứ không phải cộng trừ một con số, và đó là chủ đề của bài riêng.
Ở chặng này quyền sở hữu dữ liệu đổi chủ, vì đơn hàng là của nhân viên bán hàng còn hóa đơn là của kế toán. Chính sách lập hóa đơn nằm ở cấp sản phẩm với đúng hai lựa chọn: theo số lượng đã đặt hoặc theo số lượng đã giao, và lựa chọn đó quyết định kế toán lập hóa đơn được vào lúc nào; chọn theo số lượng đã giao mà kho chưa giao gì thì đơn nằm ở trạng thái không có gì để xuất và chặng này chưa mở ra, còn chi tiết hành vi các nút trên màn hình đơn thì thuộc bài phân biệt ERP với phần mềm kế toán.
Hóa đơn sinh ra kế thừa khách hàng theo đúng địa chỉ xuất hóa đơn trên đơn, kèm điều khoản thanh toán, các dòng hàng, nhân viên bán hàng phụ trách và mã đơn hàng nguồn. Hai trường sau tồn tại để kế toán biết được nên hỏi ai trong nội bộ và hóa đơn đi ra từ đơn nào để khi cần kiểm tra hoặc có vấn đề phát sinh, còn hóa đơn ở trạng thái Nháp thì chưa có ý nghĩa với sổ sách, chỉ khi được vào sổ thì công nợ phải thu mới được ghi nhận.
Một hệ quả hay làm người dùng ngạc nhiên là một đơn hàng có thể sinh ra nhiều phiếu giao và nhiều hóa đơn, nên quan hệ giữa các chứng từ không phải là một đổi một. Cũng ở chặng này, có một hiểu lầm tốn kém nhất trong các dự án tại Việt Nam là tưởng hóa đơn Odoo chính là hóa đơn đỏ, và tôi sẽ nói riêng ở bài khác.
Kế toán ghi nhận thanh toán và chọn sổ nhật ký tương ứng với phương thức khách đã dùng, bởi tiền vào bằng đường nào thì phải trừ đúng nguồn đó, và một hóa đơn có thể có nhiều bản ghi thanh toán nếu khách trả nhiều đợt.
Điều đáng chú ý là tới đây dữ liệu chảy ngược, bởi ngay trên màn hình đơn hàng người bán hàng thấy đã giao bao nhiêu và đã xuất hóa đơn bao nhiêu. Còn điều khoản thanh toán vốn khai từ hồ sơ khách hàng thì chảy xuống đơn, sang hóa đơn, và cuối cùng quyết định khoản này rơi vào cột nào trên báo cáo tuổi nợ.
Chính cơ chế dùng chung đó tạo ra phần khó của ERP, và phần khó này mới là thứ quyết định dự án thành hay bại.
Thứ nhất, một mã sản phẩm khai sai thuế suất chảy xuống mọi báo giá và mọi hóa đơn phát hành từ nó, nên việc phải làm không phải sửa một dòng mà là rà lại toàn bộ chứng từ đã sinh ra dọc năm chặng. Một quản lý dự án lâu năm ở công ty triển khai gọi đây là chuyện “sai dữ liệu đáng sợ hơn lỗi hệ thống”, bởi sửa là việc đơn giản, còn dữ liệu sai thì kéo theo cả chuỗi phía sau và bản ghi đã phát sinh giao dịch thì không xóa được nữa.
Thứ hai, mỗi bộ phận chỉ nhìn thấy khúc của mình, nên trong tài liệu phân tích thì phần mô tả chỗ chuyển giao giữa hai bộ phận luôn quan trọng hơn phần mô tả các thao tác bên trong một bộ phận.
Đầu tiên là đứt ngay ở đầu vào, khi đơn hàng thật được chốt bên ngoài hệ thống rồi vài ngày sau mới nhập lại. Cách xử lý không nằm ở kỹ thuật mà ở chỗ bạn cần chốt với khách xem thời điểm nào bắt buộc phải có dữ liệu trên hệ thống, rồi lấy ràng buộc đó làm căn cứ khi thiết kế quy trình.
Tiếp theo là đứt ở chỗ bàn giao sang kho, đúng như tình huống đầu bài. Người nhân viên kho phải vào phân hệ Kho và tra phiếu theo chứng từ gốc, hoặc dùng màn hình tổng quan gom theo kho để thấy hôm nay có bao nhiêu phiếu chờ xử lý. Không chốt chỗ này thì phiếu nằm im và người bán hàng lại đi tìm người kho bằng điện thoại, tức là quay về cách làm cũ.
Bên cạnh đó là đứt ở chỗ người thao tác phải ra quyết định vốn không thuộc về mình, mà lựa chọn tạo hay không tạo phiếu bổ sung là ví dụ điển hình. Mỗi lần hệ thống bật hộp thoại bắt chọn, bạn phải xác định ai là người có thẩm quyền chọn và thông tin đó tới tay người thao tác bằng đường nào.
Cuối cùng là đứt ở chỗ trao đổi diễn ra bên ngoài hệ thống. Khách đổi ngày giao, người bán hàng nhắn qua ứng dụng chat, kho làm theo tin nhắn, và tới lúc có tranh cãi thì không ai lần lại được ai đã đồng ý và đồng ý cái gì. Thói quen ghi trao đổi vào ngay chứng từ liên quan nghe rất nhỏ nhưng chính nó giữ cho dòng chảy có bằng chứng, và bạn phải hướng dẫn khách chứ họ không tự làm.
Cách chắc nhất để thuộc dòng chảy là tự chạy một lần trên hệ thống dùng thử.
Làm xong thì mở lại đơn hàng ban đầu và đếm xem có bao nhiêu chứng từ trỏ về nó. Cả dòng chảy trên chỉ chạy được khi hệ thống đã có sẵn khách hàng, sản phẩm, bảng giá và điều khoản thanh toán, và sự phân biệt giữa nhóm dữ liệu phải có trước với nhóm dữ liệu phát sinh khi vận hành chính là chuyện quyết định thứ tự làm việc của cả dự án.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận