Mã hàng 0017 đi qua API rồi xuất hiện trong Google Sheets thành 17. Dữ liệu đầu vào vẫn có đủ bốn ký tự, nhưng cột đích đã hiểu giá trị như một con số. Khi website đọc ngược để ghép SKU, sản phẩm không còn khớp. Thêm số không bằng định dạng hiển thị có thể làm ô trông đúng, trong khi giá trị dùng cho tích hợp vẫn khác.
Google Sheets RAW và USER_ENTERED là lựa chọn về cách diễn giải giá trị được gửi qua API. Bài này tập trung vào mã hàng, số hiệu hồ sơ và những chuỗi phải giữ nguyên ký tự, đồng thời giải thích cách đặt cột số và công thức bên cạnh. Ví dụ sử dụng mã giả, không chứa dữ liệu khách hàng hay hàng hóa thực tế.
Google Sheets RAW và USER_ENTERED quyết định gì?
Theo tham chiếu ValueInputOption, RAW giữ giá trị mà không phân tích theo cách nhập giao diện; USER_ENTERED xử lý như người dùng gõ vào ô. Sự khác biệt này quan trọng khi một chuỗi có hình thức giống số, ngày tháng hoặc công thức nhưng nghiệp vụ muốn giữ nó như một định danh.
RAW không biến một số đã bị xử lý trước thành chuỗi gốc. Nếu phía ứng dụng đã đổi 0017 thành số 17 rồi mới tạo JSON, lựa chọn RAW không biết hai số không từng tồn tại. Muốn giữ mã, cần giữ kiểu chuỗi từ điểm nhận dữ liệu tới payload gửi đi, rồi đọc lại giá trị đã lưu để đối chiếu.
USER_ENTERED hữu ích khi chủ đích là nhập giá trị theo quy tắc của bảng, chẳng hạn một công thức do hệ thống kiểm soát. Nhưng không nên dùng chung mặc định cho mọi cột chỉ vì dữ liệu nhìn giống nội dung thường nhập bằng tay. Mã hàng và số lượng đứng cạnh nhau có ý nghĩa khác nhau dù cả hai cùng chứa chữ số.
Xác định mã định danh trước khi chọn kiểu ghi
Hãy hỏi mã đó có được dùng để tính toán hay không. SKU 0017 thường dùng để nhận diện sản phẩm; lấy trung bình các SKU không có ý nghĩa. Số lượng 17 lại cần cộng, trừ và kiểm tra tồn kho. Hai cột nên có hợp đồng dữ liệu riêng, không dựa vào suy đoán từ một vài dòng mẫu.
Với mã định danh, mô tả độ dài nếu có quy tắc thật, ký tự được phép, phân biệt chữ hoa thường và cách xử lý khoảng trắng. Không tự điền số không cho mọi mã ngắn nếu doanh nghiệp chưa xác nhận độ dài chuẩn. Có thể mã 17 và 0017 là hai sản phẩm khác nhau, cũng có thể một trong hai là lỗi; API không quyết định điều đó.
Với cột tính toán, xác định đơn vị và miền giá trị. Số tiền có cần phần thập phân, số lượng có cho phép âm, và ô trống có khác số không không? Một hợp đồng rõ giúp tránh giải pháp cực đoan là biến mọi cột thành văn bản rồi làm hỏng tổng hợp chỉ để giữ riêng một cột mã.
Thử một payload nhỏ và đọc lại giá trị
Trên bảng thử được cấp phép, tạo hai cột mã và số lượng. Gửi mã dưới dạng chuỗi JSON, còn số lượng theo kiểu số đã kiểm tra. Dùng RAW cho lượt thử đầu, sau đó đọc lại để xác minh mã giữ đủ ký tự và số lượng vẫn phục vụ tính toán như kỳ vọng. Không chỉ nhìn ô trên giao diện.
Hướng dẫn đọc và ghi giá trị mô tả cơ chế values và các lựa chọn trả dữ liệu. Khi nghiệm thu, cần biết đang đọc giá trị đã định dạng hay giá trị chưa định dạng. Một chuỗi hiển thị 0017 nhờ định dạng số không chứng minh giá trị lưu là chuỗi 0017.
Tiếp tục thử cùng chuỗi qua USER_ENTERED trên một vùng riêng. Quan sát sự diễn giải của bảng, không gán trước kết quả cho mọi cấu hình và mọi locale. Mục tiêu của phép thử là hiểu hợp đồng của bảng đích hiện tại, chứ không chứng minh một chế độ luôn tốt hơn chế độ kia trong tất cả tác vụ.
Bộ mẫu nên có mã bắt đầu bằng số không, mã có chữ, chuỗi giống ngày và một chuỗi bắt đầu bằng dấu bằng. Những giá trị này giúp tìm lỗi diễn giải trước khi dữ liệu thật đi vào. Không dùng một bộ chỉ gồm mã không có số không rồi kết luận tích hợp đã giữ được mọi định danh.
Chuỗi giống công thức cần chủ đích rõ
Nếu nội dung do người ngoài nhập bắt đầu bằng dấu bằng, hệ thống cần biết đó là văn bản hay công thức được phép thực thi. Đừng chuyển toàn bộ dữ liệu tự do sang USER_ENTERED vì một cột khác cần công thức. Tách cột hoặc tách lượt ghi theo chức năng sẽ giúp giảm sự nhập nhằng và dễ kiểm thử hơn.
Công thức do ứng dụng tạo cũng cần danh sách trường được phép và kiểm tra vùng tham chiếu. Một đoạn văn bản khách gửi không nên trở thành công thức chỉ vì được đặt vào cùng kiểu yêu cầu. Đây là ranh giới xử lý dữ liệu của ứng dụng, không phải việc Google Sheets tự hiểu ý định kinh doanh.
Không vá số không bằng một lớp hiển thị
Định dạng hiển thị có thể làm số 17 hiện thành bốn chữ số, nhưng nếu hệ thống khác đọc giá trị số thì nó vẫn cần xử lý theo kiểu số. Với SKU dùng để đối chiếu chính xác, việc trông đúng trên màn hình chưa đủ. Cần kiểm tra cả payload gửi, giá trị lưu và kết quả trả cho ứng dụng nhận.
Cũng không nên ghép dấu nháy hoặc số không vào dữ liệu một cách ngẫu nhiên ở nhiều tầng. Khi một tầng thêm ký tự còn tầng khác coi đó là một phần mã, dữ liệu có thể lệch tiếp. Hãy chọn một quy tắc kiểu dữ liệu rõ, áp dụng tại biên nhập và kiểm tra đọc lại, thay vì dựa vào mẹo trình bày.
Nếu dữ liệu đã mất ký tự, cần quay về nguồn có thẩm quyền để phục hồi. Không suy ra mã gốc chỉ từ độ dài của những dòng bên cạnh. Một danh sách ánh xạ đã được doanh nghiệp duyệt có thể hỗ trợ sửa, nhưng sửa hàng loạt nên có bản ghi trước sau và phạm vi chính xác, không ghi đè toàn bảng đang có người làm việc.
Ranh giới với nhập CSV nằm ở đâu?
Nếu nguồn là CSV, việc phân tích tệp có thể đã làm mất kiểu hoặc ký tự trước khi gọi API. Kiểm tra CSV trước khi import website tập trung vào ranh giới tệp và dữ liệu nhập. Sau bước đó, Google Sheets vẫn có một ranh giới diễn giải riêng khi nhận payload.
Vì vậy, chẩn đoán nên đi theo chuỗi bằng chứng: ký tự trong nguồn, giá trị sau bộ đọc, kiểu JSON trước khi gửi và giá trị đọc lại từ Sheets. Nếu mã đã thành 17 ở bộ đọc CSV, đổi ValueInputOption chưa giải quyết nguồn lỗi. Nếu payload vẫn là chuỗi 0017 nhưng kết quả bị diễn giải khác, mới tập trung vào chế độ ghi và cấu hình bảng.
Cách chia tầng này cũng áp dụng khi dữ liệu đến từ form hay CRM thay vì CSV. Không cần tạo thêm quy trình nhập riêng cho mỗi nguồn; giữ một hợp đồng dữ liệu chung và ghi rõ tầng nào chịu trách nhiệm bảo toàn định danh. Điều này giúp người vận hành đưa ra yêu cầu sửa đúng nơi.
Nghiệm thu một vòng đi và về
Một lượt ghi thành công chỉ xác nhận yêu cầu được xử lý, chưa chứng minh mọi cột đúng nghĩa. Bộ nghiệm thu cần kiểm tra mã giữ nguyên, số lượng tính được, ô trống không tự biến thành số không và chuỗi giống công thức được xử lý đúng chính sách. Mỗi kỳ vọng nên gắn một giá trị mẫu cụ thể.
Ví dụ ghi dữ liệu chính thức giúp đối chiếu hình dạng yêu cầu trước khi tích hợp. Sau đó đọc lại cùng vùng bằng lựa chọn phù hợp, so sánh cả kiểu lẫn giá trị. Chạy thử qua đúng worker sẽ dùng trong vận hành, vì một ví dụ viết tay đúng chưa chứng minh bộ chuyển đổi của ứng dụng cũng đúng.
Để kiểm tra đường đọc về website, dùng mã 0017 để tra một sản phẩm giả đã biết. Xác nhận không bị gộp với mã 17 nếu hợp đồng quy định chúng khác nhau. Đừng mở một tác vụ ghi lại toàn bộ dữ liệu thật chỉ để kiểm tra một cột; một vùng thử có kiểm soát đủ giúp phát hiện lỗi diễn giải.
Nếu cần kết nối Google Sheets với website hoặc CRM mà vẫn giữ đúng mã hàng và dữ liệu tính toán, Onter có thể hỗ trợ chốt hợp đồng từng cột và kiểm tra vòng đọc lại. Nhận tư vấn & báo giá theo luồng dữ liệu thực tế; giá liên hệ.
