Khách ghi một mã PO trong form, người bán tạo một mã đơn khác, kế toán lại nhận email chỉ có tên khách. Khi cần đối chiếu, cả ba bên phải tìm lại từ đầu. Số PO trên website nên được giữ như tham chiếu của bên mua, đồng thời phân biệt với đơn người bán, hóa đơn và trạng thái thanh toán.
Hướng dẫn này dành cho doanh nghiệp nhận đơn B2B qua website hoặc cổng khách hàng. Nó không thiết kế lại hệ thống duyệt mua của khách, cũng không coi một chuỗi ký tự PO là bằng chứng đã được phép giao hàng.
Một mã tham chiếu không thay một chứng từ
PO thường được dùng để chỉ đơn mua của bên khách. Mã đơn của người bán và số hóa đơn có thể thuộc các hệ thống khác nhau. Website nên ghi tên trường rõ, không gom chúng vào ô “mã đơn” khiến người vận hành phải đoán.
Shopify mô tả số purchase order tại checkout B2B và việc hiển thị lại trên trạng thái đơn. Tài liệu cũng tách trạng thái thanh toán. Đây là ví dụ chức năng của một nền tảng, không phải lời hứa tích hợp sẵn của Onter hoặc quy tắc pháp lý chung cho PO.
Số PO trên website phải sống qua những bước nào
Tối thiểu cần đối chiếu form, trang xác nhận, email cho sales, quản trị đơn và bản xuất gửi bộ phận liên quan. Nếu có đồng bộ phần mềm, chốt trường đích, giới hạn độ dài và cách lưu giá trị gốc trước khi viết mapping.
Không tự bỏ số 0 đầu, dấu gạch hoặc đổi chữ hoa/thường nếu chưa có chính sách. Có thể lưu một bản chuẩn hóa để tìm kiếm, nhưng bản gốc khách cung cấp vẫn phải đọc được. Mã trông giống số không có nghĩa được phép chuyển thành một giá trị số học.
Ví dụ: cùng số PO nhưng không cùng giao dịch
Ví dụ giả định: công ty A và B đều dùng mã PO-2026-018. Không thể kết luận trùng đơn chỉ dựa mã PO. Ngữ cảnh có thể cần công ty, địa điểm, lần phát hành hoặc dòng hàng. Ngược lại, cùng khách gửi lại một yêu cầu cũng chưa chắc là một đơn mới.
Giả sử PO được sửa từ lượng 10 sang 8. Người bán cần biết bản nào đang được khách xác nhận và đơn nội bộ đã xử lý đến đâu. Không ghi đè tham chiếu cũ rồi mất dấu lý do thay đổi. Mã PO còn có thể được dùng cho nhiều đợt giao theo chính sách hai bên; website phải giữ quan hệ đã thống nhất thay vì mặc định một mã chỉ có một đơn.
Bốn trường nên tách trước khi tích hợp
- Tham chiếu PO gốc của bên mua.
- Định danh công ty hoặc tài khoản mua được xác nhận.
- Mã đơn của người bán và quan hệ với tham chiếu.
- Trạng thái xác nhận, thanh toán và xử lý thuộc nguồn nào.
Danh sách này là thiết kế biên tập để khảo sát, không phải biểu mẫu bắt buộc. Nếu khách chưa có PO, có thể nhận yêu cầu ở trạng thái phù hợp hoặc yêu cầu bổ sung trước một bước xác định. Đừng tạo một mã PO giả để vượt trường bắt buộc.
Không nhầm với PunchOut hoặc hiệu lực báo giá
PunchOut xử lý việc chuyển giỏ về ứng dụng mua sắm và ranh giới duyệt đơn. Trường tham chiếu PO trên một website độc lập là phạm vi hẹp hơn. Nó không tự kết nối được mọi phần mềm mua hàng của khách.
Hiệu lực báo giá cũng cần đối chiếu riêng. Có PO không bảo đảm giá hoặc điều kiện của một bản báo giá cũ vẫn được áp dụng. Người phụ trách phải xác nhận các quan hệ đó trước khi hệ thống cho chuyển bước.
Nghiệm thu bằng dữ liệu dễ bị mất nghĩa
Thử PO có số 0 đầu, ký tự tiếng Việt nếu thực tế dùng, độ dài gần giới hạn, hai công ty cùng mã và một bản sửa đổi. Tìm lại được từ cả mã nội bộ và mã khách. Nếu email đã đúng nhưng file xuất bị cắt mã, luồng đối chiếu vẫn chưa hoàn chỉnh.
Với thiết kế website Onter, trường tham chiếu, bản xuất và kết nối riêng cần chốt phạm vi. Chi phí phụ thuộc số điểm dữ liệu đi qua, quyền sửa và tích hợp, không chỉ việc thêm một ô nhập. Doanh nghiệp vẫn sở hữu quy trình xác nhận chứng từ và giao hàng.
Bắt đầu bằng một đơn thật đã ẩn dữ liệu khách: vẽ đường mã PO đi qua từng bộ phận, đánh dấu nơi thường phải nhập lại. Khi đầu vào và quyền sửa đã rõ, mới quyết định phần nào cần tự động hóa; không cần mua một luồng lớn chỉ để giữ một tham chiếu nhất quán.
