Một nhóm triển khai ghi đủ thời gian nhưng cuối kỳ vẫn khó trả lời khách: trong số giờ đó, phần nào thuộc hợp đồng và phần nào chưa được phép đưa vào hóa đơn? Vấn đề thường nằm ở quan hệ giữa công việc, dòng dịch vụ đã bán và quyết định tính phí. Sửa tổng giờ cho khớp số tiền muốn thu sẽ làm mất lịch sử thực hiện, còn cộng tất cả giờ đã ghi vào hóa đơn có thể đưa cả việc nội bộ vào phạm vi khách phải trả.
Bài này dùng tình huống giả định để tổ chức việc đối chiếu giờ timesheet được tính phí. Các cơ chế sản phẩm được đối chiếu tài liệu Odoo 19; quy tắc phân loại công việc và người duyệt là đề xuất vận hành, cần thống nhất theo hợp đồng thực tế. Không có thao tác xuất hóa đơn hay xử lý dữ liệu khách hàng nào được thực hiện trong ví dụ.
Bắt đầu từ một tuần làm việc
Giả sử một đội dịch vụ có bốn dòng công việc cho cùng dự án. Hai giờ xử lý yêu cầu nằm trong phạm vi đã bán; một giờ chỉnh lại lỗi nội bộ; nửa giờ trao đổi về yêu cầu bổ sung; một giờ nghiên cứu công cụ để dùng cho nhiều dự án. Tổng công sức ghi nhận là 4,5 giờ. Con số ấy hữu ích cho quản lý nguồn lực, nhưng chưa tự trả lời số giờ được tính cho khách.
Ở đây, giả định hợp đồng cho phép tính hai giờ xử lý yêu cầu, không tính giờ sửa lỗi nội bộ và nghiên cứu chung; nửa giờ bổ sung đang chờ xác nhận. Đây là chính sách của tình huống minh họa, không phải quy tắc mặc định của Odoo hoặc mọi doanh nghiệp dịch vụ. Kết quả đối chiếu tạm thời là 2 giờ đủ căn cứ, 0,5 giờ chờ quyết định và 2 giờ nội bộ. Tổng vẫn bằng 4,5 giờ, không phải chỉ còn hai giờ vì các dòng còn lại đã bị xóa.
Cần giữ được câu hỏi phía sau từng dòng: làm việc gì, cho đầu việc nào, theo yêu cầu nào và ai có quyền xác nhận phạm vi. Mô tả “hỗ trợ khách” quá rộng sẽ không giúp người duyệt phân biệt sửa lỗi, hướng dẫn sử dụng và yêu cầu phát triển mới. Mô tả đủ rõ cũng không cần chứa mật khẩu, dữ liệu cá nhân hay toàn bộ nội dung trao đổi với khách.

Giờ timesheet được tính phí dựa trên căn cứ nào?
Trong tài liệu Odoo 19 Timesheets, người dùng ghi, xem và xác nhận thời gian theo dự án. Với dự án có tính phí, dòng thời gian cần liên kết Sales Order Item để có thể đưa giờ vào quy trình lập hóa đơn. Đó là liên kết đến dòng dịch vụ trên đơn bán hàng, không chỉ là tên khách xuất hiện trong mô tả công việc.
Vì vậy, có thể đọc dữ liệu theo bốn lớp: công sức đã ghi, công việc đã được kiểm tra, quan hệ với dòng dịch vụ và lượng đã lập hóa đơn. Một dòng được xác nhận về nội dung chưa chứng minh khách đã chấp thuận một yêu cầu ngoài hợp đồng. Một dòng đã gắn đơn bán hàng cũng cần kiểm tra đúng dòng dịch vụ, đúng khách và đúng cách tính của sản phẩm. Quyền sửa hoặc xác nhận timesheet cần được cấu hình theo vai trò thực tế, không cấp rộng chỉ để người lập báo cáo nhìn được mọi dữ liệu.
Màu thể hiện tổng giờ trong màn hình timesheet cũng không nên được dùng thay quyết định thương mại. Đủ thời gian theo lịch làm việc của nhân viên trả lời câu hỏi về ghi nhận công sức. Nó không chứng minh mọi giờ trong ngày đều được thu tiền. Ngược lại, một ngày có ít giờ tính phí không tự chứng minh nhân viên thiếu công hoặc làm việc kém hiệu quả.
Gói trả trước cần đọc theo gói
Với hỗ trợ trả trước, hóa đơn có thể đã được tạo theo số giờ bán trước khi đội kỹ thuật ghi giờ thực hiện. Không thể kết luận “chưa làm thì chưa được lập hóa đơn” cho mọi loại dịch vụ. Khi rà cuối kỳ, cần biết đơn đang bán một gói giờ, một đầu việc trọn gói hay dịch vụ tính theo thời gian thực tế, rồi đối chiếu đúng chỉ tiêu.
Dịch vụ trả sau cần căn cứ riêng
Hướng dẫn Track and bill time mô tả riêng hỗ trợ trả trước và trả sau. Trong luồng được tài liệu mô tả, thời gian trên ticket liên hệ với dòng đơn bán hàng và lượng Delivered; việc tạo hóa đơn là một bước tiếp theo. Không nên lấy một trường Delivered rồi gọi đó là tiền đã thu, cũng không coi số giờ gói còn lại là quyết định tự động cho phép thu thêm khi vượt gói.
Doanh nghiệp cần chốt cách xử lý vượt phạm vi trước khi nhân viên nhận thêm việc: dừng để xin xác nhận, ghi nhận vào mục chờ duyệt hay sử dụng thỏa thuận khác. Tài liệu phần mềm không thay thế thỏa thuận này. Nếu cấu hình thực tế đã tự liên kết một dòng dịch vụ theo khách, người kiểm tra vẫn cần rà lại đúng gói, nhất là khi khách có nhiều đơn đang mở.

Đối chiếu từng dòng, giữ nguyên công sức
Với tuần giả định ở trên, hãy bắt đầu từ một danh sách có thể truy về nguồn. Mỗi dòng giữ mã timesheet, ngày, dự án, đầu việc, thời lượng và mô tả vừa đủ. Phần rà soát bổ sung căn cứ hợp đồng hoặc yêu cầu, dòng dịch vụ dự kiến, người quyết định và kết luận tại thời điểm chốt. Đây là mô hình báo cáo đề xuất, không khẳng định các trường bổ sung đều có sẵn trong mọi bản cài Odoo.
| Công việc | Giờ đã ghi | Kết luận theo giả định |
|---|---|---|
| Xử lý yêu cầu trong phạm vi | 2 | Đủ căn cứ đối chiếu dòng dịch vụ |
| Chỉnh lỗi nội bộ | 1 | Giữ công sức, không tính cho khách |
| Trao đổi yêu cầu bổ sung | 0,5 | Chờ xác nhận phạm vi |
| Nghiên cứu công cụ chung | 1 | Theo dõi nội bộ |
Người kiểm tra không cần biến mọi ngoại lệ thành một mã lỗi kỹ thuật. Nếu dòng bổ sung chưa có xác nhận, thông tin cần bổ sung là người có thẩm quyền và phạm vi đã thống nhất. Nếu dòng đã đủ căn cứ nhưng không xuất hiện ở đơn phù hợp, lúc đó mới kiểm tra liên kết và cấu hình. Hai tình huống có cách xử lý khác nhau; gộp chung thành “không lên hóa đơn” sẽ khiến kỹ thuật sửa dữ liệu thay cho quyết định kinh doanh.
Khi hợp đồng được điều chỉnh sau đó, giữ được lịch sử quyết định sẽ giúp giải thích vì sao nửa giờ ban đầu chờ duyệt rồi mới được tính. Không sửa mô tả cũ thành một yêu cầu khác để làm dữ liệu trông hợp lệ. Cũng không đổi ngày thực hiện sang kỳ mới chỉ để đưa vào đợt hóa đơn thuận tiện hơn. Việc sửa sai cần có căn cứ, người thực hiện và cách đối chiếu trước sau theo công cụ đang dùng.
Chốt kỳ bằng phạm vi đã thống nhất
Trước khi lập hóa đơn, chọn một mốc chốt và xem những dòng đủ căn cứ trong phạm vi ấy đã gắn đúng dịch vụ chưa. Sau bước lập hóa đơn, đối chiếu lượng đã đưa vào chứng từ với tập dòng đã chọn. Đừng chỉ kiểm tra tổng tiền: hai sai lệch ngược chiều có thể bù nhau về số học trong khi một đầu việc bị bỏ sót và đầu việc khác bị tính thừa.
Tài liệu Invoicing policies phân biệt cách lập hóa đơn theo lượng đặt và lượng giao. Khi áp dụng vào dịch vụ, cần đọc thêm cấu hình sản phẩm và luồng dịch vụ tương ứng, không lấy ví dụ giao hàng vật lý làm bảo đảm cho mọi timesheet. Một báo cáo đối chiếu nên ghi rõ đang đọc lượng nào và tình trạng chứng từ nào.
Đợt rà soát nhỏ có thể dùng chính bốn dòng minh họa để thử: giữ đầy đủ 4,5 giờ công sức, không tự tính dòng nội bộ cho khách, không tự duyệt dòng bổ sung và truy được dòng dịch vụ của phần đã đủ căn cứ. Thêm một trường hợp gắn nhầm đơn của cùng khách để kiểm tra báo cáo có phát hiện sai liên kết hay chỉ cộng tổng theo tên khách. Đây là đề xuất nghiệm thu, chưa phải kết quả kiểm thử hệ thống.
Đội dự án chịu trách nhiệm mô tả công việc; người có thẩm quyền thương mại xác nhận phạm vi; người lập hóa đơn đối chiếu chứng từ theo phân quyền. Có thể một người kiêm nhiều vai trò trong đội nhỏ, nhưng cần biết họ đang quyết định điều gì. Automation chỉ nên hỗ trợ tập hợp và chỉ ra dòng thiếu căn cứ, không tự suy ra quyền thu tiền từ một đoạn mô tả hay email chưa được xác minh.
Nếu nhu cầu thực tế là đối chiếu giờ hiện diện, lịch ca và bảng công tính lương, hãy dùng phạm vi đối chiếu chấm công, lịch ca và bảng lương. Bài này giải quyết giờ công của dự án liên hệ với phạm vi dịch vụ bán cho khách; hai báo cáo cần giữ mục đích và quyền truy cập riêng. Khi cần tích hợp, có thể trao đổi với Onter bằng một mẫu giả lập có dòng công việc, dòng dịch vụ và ngoại lệ cần rà, không gửi timesheet hay hợp đồng thật qua biểu mẫu công khai.

