Từ theo dõi thời gian đến hóa đơn: từ bản ghi đến PDF có thương hiệu

Bạn sẽ xây gì và tại sao nó quan trọng

Một ứng dụng từ theo dõi thời gian đến hóa đơn khắc phục một mớ hỗn độn phổ biến: giờ làm việc bị phân tán trong lịch, chat và ghi chú. Rồi đến ngày lập hóa đơn thì ai đó phải ghép lại cả tháng bằng tay. Đó là lúc xảy ra lỗi: thời gian có thể bị bỏ sót, tỷ lệ sai, dòng trùng lặp, hoặc tổng không khớp.

Ứng dụng này dành cho bất kỳ ai tính phí theo giờ và muốn một quy trình lặp lại: freelancers quản lý nhiều khách hàng, agency có nhiều người ghi thời gian cho cùng dự án, và các đội nội bộ tính chi phí cho khách hàng hoặc phòng ban.

Mục tiêu thực tế: ghi nhận các mục thời gian theo dự án, gom chúng vào một bản ghi hóa đơn, và tạo PDF thương hiệu mà khách hàng có thể hiểu. Khi quy trình đó đáng tin cậy, việc lập hóa đơn không còn là cuộc chạy đua hàng tháng nữa.

Giữ "đơn giản trước" thường có nghĩa:

• Một cách để ghi thời gian (ngày, dự án, giờ, ghi chú)
• Một quy tắc tỷ lệ duy nhất (theo dự án hoặc theo người)
• Một hóa đơn cho mỗi khách hàng trong mỗi kỳ
• Một bố cục PDF với logo và thông tin doanh nghiệp
• Trạng thái rõ ràng (Draft, Sent, Paid)

Một kịch bản nhỏ: một studio hai người theo dõi thời gian cho “Client A - Website Updates.” Mỗi người ghi mục trong tuần. Đến thứ Sáu, bạn tạo hóa đơn cho dự án và khoảng ngày đó, ứng dụng biến các mục thành dòng hóa đơn và PDF sẵn sàng gửi mà không cần gõ lại.

Nếu bạn dùng nền tảng no-code như AppMaster, hãy làm đúng dữ liệu và luồng công việc trước khi thêm các tính năng phụ như biên lai, đa tiền tệ, chiết khấu hoặc phê duyệt. Những thứ đó dễ thêm khi luồng cốt lõi nhanh, chính xác và khó làm hỏng.

Các tính năng cốt lõi nên có (và những gì nên bỏ trước)

Một phiên bản nhỏ ban đầu giúp bạn có thể gửi hóa đơn sớm hơn. Tập trung vào ba việc: ghi thời gian, biến thời gian thành các dòng hóa đơn rõ ràng, và tạo PDF mà khách hàng hiểu ngay.

Bắt đầu với vài bản ghi cốt lõi (sau này có thể đổi tên, nhưng cấu trúc quan trọng): Client, Project, Time Entry, Invoice, và Invoice Line.

Giữ quy trình hóa đơn đơn giản bằng một trường trạng thái duy nhất trên bản ghi Invoice. Draft, Sent và Paid đáp ứng hầu hết nhu cầu cho khá lâu.

Các hành động cần có nên khớp với những gì xảy ra hàng tuần:

• Ghi thời gian (nhập thủ công thường là nhanh nhất để xây và dễ sửa)
• Phê duyệt thời gian (dù chỉ là trạng thái “Approved”)
• Tạo hóa đơn từ thời gian đã phê duyệt
• Xuất PDF

"Thương hiệu" không có nghĩa là cầu kỳ. Nó có nghĩa là nhất quán và đáng tin: logo, thông tin doanh nghiệp, số hóa đơn và ngày, tổng rõ ràng, và hướng dẫn thanh toán.

Những gì nên bỏ trước: thuế, chiết khấu, đa tiền tệ và tệp đính kèm. Chúng hữu ích nhưng đưa vào nhiều trường hợp cạnh (làm tròn, luật từng vùng, tỷ giá hối đoái, lưu trữ file) làm chậm phát hành đầu tiên.

Mô hình dữ liệu: các bản ghi cần và trường quan trọng

Một ứng dụng từ theo dõi thời gian đến hóa đơn sống hoặc chết bởi mô hình dữ liệu. Giữ nó nhỏ và dự đoán được để tổng luôn khớp với những gì bạn đã hứa với khách hàng.

Một tập bảng tối thiểu thường trông như sau:

• Client: tên, email xuất hóa đơn, địa chỉ xuất hóa đơn, tiền tệ mặc định, điều khoản thanh toán (ví dụ Net 14)
• Project: client_id, tên dự án, tỷ lệ giờ mặc định (tùy chọn), cờ active
• Time entry: project_id, person (tên hoặc user_id), date, duration (giờ), mô tả, rate_at_time, billable (yes/no), invoiced_invoice_id (để trống cho đến khi được lập hóa đơn)
• Invoice: client_id, project_id (tùy chọn), số hóa đơn, ngày phát hành, ngày đáo hạn, status, subtotal, tax, total

Tỷ lệ là nơi các ứng dụng dễ rối. Chọn một cách và giữ nó: tỷ lệ theo dự án, theo người, hoặc cố định theo task/dịch vụ.

Ngay cả khi lưu tỷ lệ mặc định trên dự án hoặc người, hãy sao chép tỷ lệ thực tế vào mỗi time entry dưới trường rate_at_time khi mục được tạo (hoặc được phê duyệt). Điều đó tránh bất ngờ khi tỷ lệ thay đổi sau này. Hóa đơn nên phản ánh điều đúng vào thời điểm công việc được thực hiện.

Với các time entry, bạn thường có thể bỏ qua trạng thái riêng và dựa vào việc trường invoiced_invoice_id có rỗng hay không. Với hóa đơn, giữ trạng thái chặt: Draft, Ready, Sent, Paid (và thêm Void nếu cần trạng thái hủy rõ ràng).

Trong AppMaster, Data Designer ánh xạ rõ ràng tới PostgreSQL và giúp giữ các quan hệ rõ ràng mà không phải nhân bản trường khắp nơi.

Ghi nhận thời gian theo dự án (UX đơn giản)

Ghi nhận thời gian là nơi ứng dụng trở nên nhẹ nhàng hoặc bị bỏ qua. Giữ phiên bản đầu tiên đơn điệu và nhanh: một màn hình, một hành động chính, và ít lựa chọn nhất có thể.

Chọn một phương thức ghi nhận ban đầu. Nhập thủ công thường thắng lúc đầu vì phù hợp với mọi người và dễ rà soát. Đồng hồ bấm giờ (timer) có thể thêm sau khi bạn biết người dùng theo dõi ngày của họ ra sao. Nếu thêm timer, vẫn cho phép chỉnh sửa thủ công cho các trường hợp dừng quên.

Đặt các trường giúp bảo vệ chất lượng thanh toán là bắt buộc:

• Project (hoặc client + project)
• Date
• Duration (giờ và phút)
• Mô tả ngắn (cái mà khách hàng sẽ nhận ra)
• Person (nếu có nhiều người cộng tác)

Quyết định quy tắc làm tròn sớm vì chúng ảnh hưởng đến niềm tin và tổng. Cách phổ biến là làm tròn theo bước 6 phút (0.1 giờ). Rõ ràng rằng bạn làm tròn mỗi mục hay tổng hàng ngày. Làm tròn mỗi mục đơn giản hơn để giải thích và kiểm toán.

Nếu nhiều người tham gia vào việc lập hóa đơn, thêm bước phê duyệt nhẹ. Quy tắc thực tế: khi đã phê duyệt, mục bị khóa để không thể sửa mặc định. Nếu cần thay đổi, yêu cầu vai trò quản lý mở lại và ghi ai đã sửa và vì sao.

Chuyển thời gian thành dòng hóa đơn (quy tắc gom)

Việc gom là nơi các bản ghi thô trở thành các dòng hóa đơn mà khách hàng có thể hiểu. Giữ quy tắc đơn giản và lặp lại để bạn tin tưởng mọi hóa đơn tạo ra.

Bắt đầu với một hành động: chọn khách hàng và khoảng ngày, rồi chỉ kéo các time entry chưa được lập hóa đơn. Bộ lọc này là rào chắn ngăn lập hóa đơn hai lần. Nếu một mục thiếu khách hàng hoặc dự án, coi nó là “chưa sẵn sàng lập hóa đơn” và giữ nó ngoài quá trình gom cho đến khi sửa xong.

Cách gom các mục thành dòng hóa đơn

Việc gom quyết định bạn tạo bao nhiều dòng và khách hàng dễ rà soát thế nào. Chọn mặc định, và thêm một tùy chọn bật/tắt nếu cần linh hoạt.

Các tùy chọn gom phổ biến:

• Theo dự án
• Theo người (hữu ích khi tỷ lệ khác nhau)
• Theo ngày hoặc tuần
• Theo task/danh mục (Design vs Development)

Dù chọn gì, mỗi dòng nên hiển thị: nhãn rõ ràng, tổng giờ, tỷ lệ và số tiền dòng. Nếu tỷ lệ có thể thay đổi, dùng rate_at_time lưu trên mỗi mục (hoặc bảng tỷ lệ với ngày hiệu lực), chứ không phải một “tỷ lệ hiện tại” duy nhất.

Đánh dấu là đã lập hóa đơn (nhưng đừng tự đóng cửa)

Khi bạn thêm mục vào hóa đơn, lưu ID hóa đơn lên mỗi time entry. Điều này tạo dấu vết kiểm toán và ngăn cùng mục bị kéo lần nữa.

Sửa lỗi xảy ra. Nếu bạn xóa một dòng khỏi hóa đơn, đừng xóa lịch sử. Bỏ liên kết các time entry bị ảnh hưởng (xóa invoice ID), tính lại tổng, và lưu một ghi chú ngắn như “Removed 2.0h, wrong project.”

Trong AppMaster, điều này phù hợp như một quá trình nghiệp vụ: truy vấn các mục chưa được lập hóa đơn, gom chúng, tạo dòng hóa đơn, rồi cập nhật mỗi mục với tham chiếu hóa đơn.

Bản ghi hóa đơn: tổng, đánh số và trạng thái

Bản ghi hóa đơn là khung bạn có thể gửi, theo dõi và kiểm toán sau này. Nó nên ổn định ngay cả khi ai đó sửa tên dự án hoặc thay đổi tỷ lệ mặc định.

Phần header hóa đơn thực tế gồm:

• Số hóa đơn (duy nhất, dễ đọc)
• Ngày phát hành và ngày đáo hạn
• Thông tin người nhận (tên khách hàng, địa chỉ xuất hóa đơn, mã số thuế nếu cần)
• Ghi chú (hướng dẫn thanh toán, lời cảm ơn ngắn)
• Tiền tệ (và tùy chọn lưu tỷ giá nếu bạn lập hóa đơn quốc tế)

Giữ tổng dự đoán được. Subtotal là tổng các dòng hóa đơn. Sau đó áp dụng chiết khấu (số tiền cố định hoặc phần trăm), tính thuế (thường trên subtotal sau chiết khấu), và lưu tổng cuối cùng. Lưu tỷ lệ thuế và giá trị chiết khấu đã dùng để có thể tái tạo hóa đơn sau này.

Đánh số hóa đơn không cần phức tạp. Chọn một mẫu và dùng đều: theo thứ tự (000123), theo năm (2026-00123), hoặc tiền tố khách hàng + dãy (ACME-014). Sự nhất quán quan trọng hơn sự hoàn hảo.

Trạng thái nên tập trung cho giao tiếp và kiểm soát nội bộ:

• Draft (có thể sửa, chưa gửi)
• Ready (tổng đã khóa)
• Sent (đã chia sẻ với khách hàng)
• Paid (xác nhận thanh toán)
• Overdue (quá hạn)
• Void (hủy, giữ cho lịch sử)

Tạo PDF thương hiệu mà khách hàng có thể đọc

Một PDF hóa đơn tốt trả lời nhanh hai câu hỏi: đang được tính phí gì, và thanh toán như thế nào. Tạo PDF từ bản ghi hóa đơn (không phải từ các time entry thô) để tài liệu luôn khớp số hóa đơn, tổng và trạng thái.

Hầu hết khách hàng mong đợi cùng các khối thông tin mỗi lần:

• Header với tên doanh nghiệp bạn, số hóa đơn và ngày hóa đơn
• Thông tin khách hàng (công ty, tên liên hệ, địa chỉ xuất hóa đơn, mã số thuế nếu cần)
• Dòng mục (mô tả, số lượng hoặc giờ, tỷ lệ, tổng dòng)
• Tổng (subtotal, thuế, chiết khấu, tổng chung)
• Điều khoản thanh toán (ngày đáo hạn, phương thức chấp nhận, ghi chú phí trễ nếu dùng)

Thương hiệu quan trọng, nhưng khả năng đọc còn quan trọng hơn. Dùng một màu nhấn, font rõ ràng, và làm cho tổng dễ quét.

Vấn đề bố cục sẽ xuất hiện với dữ liệu thực. Thử với mô tả dài và hơn 30 dòng mục. Đảm bảo tiêu đề cột lặp ở trang mới và khối tổng giữ nguyên không bị tách.

Nếu bạn sinh PDF trong AppMaster, xử lý PDF như một artifact của hóa đơn: lưu file (hoặc tham chiếu lưu trữ) trên bản ghi Invoice với timestamp và phiên bản. Điều này giúp dễ gửi lại đúng tài liệu khách hàng đã thấy.

Kế hoạch xây từng bước (quy trình no-code)

Quyết định đâu là “nguồn sự thật.” Time entries là dữ kiện thô. Hóa đơn là snapshot bạn có thể gửi và kiểm toán sau.

1) Mô hình dữ liệu trước

Tạo các bảng và quan hệ, sau đó thêm vài trường chất lượng khi những phần cơ bản ổn định:

• Clients
• Projects
• Time Entries
• Invoices
• Invoice Lines

2) Xây hai màn hình đơn giản

Giữ UI tối giản:

• Form nhập time entry: project, date, duration, notes, save
• Xem hóa đơn: client, kỳ, dòng, tổng, trạng thái

UI web thường đủ cho quản trị và xem xét. Thêm màn hình di động sau nếu cần ghi thời gian khi di chuyển.

3) Tự động hóa logic gom

Xây một flow như: chọn client + khoảng ngày, fetch các mục chưa lập hóa đơn, gom chúng, tạo các dòng hóa đơn. Đánh dấu các mục là đã lập hóa đơn chỉ sau khi hóa đơn được phê duyệt hoặc chuyển sang Ready.

4) Sinh và lưu PDF

Thêm hành động “Generate PDF” kéo header hóa đơn, thông tin khách hàng và các dòng vào mẫu, rồi lưu kết quả lên bản ghi Invoice.

Ví dụ: từ nhật ký thời gian hàng tuần đến hóa đơn sẵn gửi cho khách

Một agency 3 người có một khách hàng, Northstar Co, và tính phí cho hai dự án trong hai tuần: Website Refresh và Monthly Support. Đội gồm Alex (design), Priya (dev), và Sam (PM). Mọi người ghi thời gian hàng ngày, chọn client, project, date và mô tả ngắn.

Mỗi ngày, các mục được lưu là Draft. Vào thứ Sáu chiều, Sam mở màn hình rà soát lọc theo “Tuần này, Northstar Co”. Anh sửa hai ghi chú (“Homepage hero” thành “Hero”), xác nhận billable vs non-billable, và khóa tuần.

Đây là ví dụ các mục trong tuần:

Khi Sam nhấn “Create invoice”, ứng dụng gom các mục thành dòng hóa đơn theo quy tắc đơn giản: gom theo dự án và tỷ lệ billable, tổng giờ, và lấy mô tả ngắn. Hóa đơn có 3 dòng:

Hệ thống gán số hóa đơn (ví dụ NS-2026-014), tính subtotal và thuế, và đặt trạng thái là Ready. Nhấn thêm lần nữa để sinh PDF thương hiệu (logo, địa chỉ khách, chi tiết dòng, tổng, hướng dẫn thanh toán). Sau khi gửi, trạng thái cập nhật thành Sent và các time entry liên quan được đánh dấu là invoiced để không thể lập hóa đơn lại.

Lỗi phổ biến và cách tránh

Hầu hết vấn đề không phải là toán học. Là vấn đề quy trình.

Không khóa các mục đã lập hóa đơn. Nếu mọi người có thể sửa hoặc chọn lại cùng các mục cho hóa đơn mới, cuối cùng sẽ xảy ra lập hóa đơn hai lần. Khắc phục bằng tham chiếu hóa đơn trên mỗi time entry, và ẩn mục đã lập hóa đơn khỏi view “sẵn sàng lập hóa đơn”.

Viết lại lịch sử khi thay đổi tỷ lệ. Nếu bạn tính toán chỉ dựa trên tỷ lệ “hiện tại” của dự án hoặc người, thay đổi tỷ lệ sẽ làm thay đổi hóa đơn cũ. Sao chép tỷ lệ hiệu lực vào rate_at_time trên mỗi mục.

Chỉnh sửa thời gian đã phê duyệt mà không có dấu vết kiểm toán. Thêm “Approved by”, “Approved at”, và một ghi chú ngắn cho các sửa đổi sau khi phê duyệt.

PDF bị vỡ với dữ liệu thực. Mô tả dài, nhiều dòng mục và số lớn sẽ làm template bị stress.

Các sửa nhanh để tránh hầu hết lỗi bố cục:

• Đặt độ dài mô tả tối đa và chuyển phần dư sang mục ghi chú
• Cho phép xuống dòng và thử với hơn 30 dòng
• Giữ header gọn để bảng có chỗ
• Dùng định dạng số nhất quán (tiền tệ, chữ số thập phân)

Luồng trạng thái mơ hồ. Không có quy tắc rõ ràng, hóa đơn có thể bị gửi hai lần hoặc không bao giờ gửi.

Luồng đơn giản và an toàn: Draft -> Ready -> Sent -> Paid. Chỉ cho phép roll-up khi ở Draft, và chỉ cho phép sinh PDF khi tổng đã khóa.

Danh sách kiểm tra ngắn và bước tiếp theo thực tế

Trước khi gửi hóa đơn, làm rà soát nhanh. Nó ngăn hầu hết lỗi phổ biến: tổng sai, thiếu thông tin, và PDF trông ổn trên màn hình nhưng bị lỗi khi in.

Danh sách kiểm tra trước khi gửi:

• Thông tin khách hàng đầy đủ (tên pháp lý, địa chỉ xuất hóa đơn, đúng liên hệ)
• Kỳ hóa đơn đúng (ngày bắt đầu và kết thúc khớp công việc)
• Tổng khớp (subtotal, thuế, tổng chung khớp với mục, tỷ lệ và làm tròn)
• Không thiếu hoặc trùng thời gian (không có mục chưa được lập hóa đơn, không có mục lặp đôi)
• Các trường vận hành sạch (số hóa đơn duy nhất, trạng thái đúng, PDF đã lưu trên hóa đơn)

Sau đó xem trước PDF với “mắt in ấn”. Kiểm tra vị trí logo, địa chỉ dài, xuống dòng trong bảng và ngắt trang. Thử cả hóa đơn ngắn (1-2 dòng) và dài (20+ dòng).

Bước tiếp theo khi cơ bản ổn định:

• Gửi hóa đơn qua email với mẫu thống nhất
• Thêm thanh toán Stripe và đánh dấu hóa đơn là Paid tự động
• Thêm phân quyền để chỉ đúng vai trò mới sửa tỷ lệ, phê duyệt thời gian, hoặc thay đổi trạng thái

Nếu bạn muốn xây nhanh và lặp lại mà không viết lại mọi thứ từ đầu, AppMaster (appmaster.io) là một lựa chọn thực tế để tạo ứng dụng lập hóa đơn no-code với cơ sở dữ liệu thực, logic nghiệp vụ và tạo PDF, rồi tái sinh mã nguồn sạch khi yêu cầu thay đổi.

Nếu chỉ cải thiện một việc trong tuần này, hãy làm cho “thời gian chưa lập hóa đơn” không thể bị bỏ sót. Chỉ điều đó thôi cũng cứu giờ và bảo vệ doanh thu.