Đang tải nội dung...
Bảng tính lộn xộn thì khoan vội viết công thức

Bạn cộng doanh thu nhưng tổng không khớp.
Mục lục bài viết4 mục
Công thức cộng không báo lỗi, nhưng tổng doanh thu vẫn lệch. Bạn đổi vùng tính rồi thử lại, con số chẳng khá hơn. Tới lúc nhìn kỹ cột tiền, mới thấy ba kiểu ghi: “150000”, “150 nghìn” và “chờ chốt”. Công thức đang nhận những giá trị không cùng cách hiểu.
Làm sạch bảng tính trước khi tính toán là kiểm dữ liệu có đúng loại, đúng phạm vi và đủ điều kiện để dùng không. Cùng theo tình huống giả định: Duy nhận bảng bán hàng từ ba cửa hàng để tổng hợp tuần. Cậu cần một con số giải thích được, không chỉ một bảng nhìn gọn hơn.
Giữ một bản dữ liệu gốc

Duy lưu nguyên các file vừa nhận rồi tạo bản xử lý riêng. Cậu ghi nguồn, khoảng thời gian và người gửi bên cạnh từng file. Nếu sau này phát hiện một giá trị bất thường, cậu còn đường quay lại xem ban đầu cửa hàng đã ghi gì.
Tên file cần giúp nhận ra vai trò của từng bản. Bản nhận từ cửa hàng khác với bản đã xử lý và bản dùng báo cáo. Cách đặt tên file dễ tìm lại giúp tránh cảnh chỉnh nhầm nguồn chỉ vì hai file đều mang tên “tổng hợp mới”.
Trước khi ghép, Duy hỏi một câu tưởng nhỏ: file gửi thêm là phần bổ sung hay bản đầy đủ thay thế? Nếu bảng mới đã chứa các đơn hôm qua mà cậu nối thẳng vào bảng cũ, cùng một đơn có thể xuất hiện hai lần. Lỗi lúc này nằm ở cách nhận dữ liệu, chưa phải công thức.
Cậu cũng xác nhận bảng có gồm đơn hủy hoặc đơn chưa giao không. Người gửi có thể đã giải thích trong tin nhắn, nhưng file lại không ghi rõ. Duy lưu thông tin đó cùng nguồn để không quên khi đến bước lọc và tính tổng.
Trong bản xử lý, cậu giữ ghi chú những bước làm thay đổi dữ liệu: chuyển cách ghi tiền, xác nhận ngày, tách dòng cần kiểm. Không cần kể từng lần đổi màu. Mục đích là để người khác biết vì sao số dòng hoặc giá trị sau xử lý khác với lúc nhận.
Nếu nhiều người cùng xử lý, nhóm thống nhất ai làm phần nào và bản nào đang được dùng. Duy không muốn vừa chuẩn hóa tên cửa hàng xong thì đồng nghiệp lại nhập thêm cách viết cũ. Quy tắc nhập mới cần được nói rõ cùng lúc sửa dữ liệu đã có.
Một cột nên có một loại thông tin
Cột tiền hàng là nơi Duy bắt đầu. Cậu tách ghi chú “chờ chốt” sang trạng thái riêng. Giá chưa biết không được tự biến thành số không. Người đọc có thể hiểu số không là không thu tiền, trong khi thực tế đơn đó còn thiếu giá.
Với dòng “150 nghìn”, Duy xác nhận đơn vị tiền và ý nghĩa trước khi chuyển thành giá trị dùng tính toán. Cậu không áp dụng một quy tắc cho cả cột chỉ vì vài dòng đầu có vẻ giống nhau. Trong dữ liệu còn có thể có cách ghi khác hoặc đơn dùng đơn vị khác.
Mã đơn là chuyện khác. Một mã như “00125” nhìn giống số nhưng đang đóng vai trò nhận diện. Nếu bỏ số không đầu, việc đối chiếu với nguồn có thể sai. Duy xác định ý nghĩa của cột trước khi chọn cách lưu, thay vì đổi mọi thứ trông giống số sang dạng số.
Đến ngày giao “04/05”, cậu dừng lại hỏi quy ước của nguồn. Đây là ngày bốn tháng năm hay tháng bốn ngày năm? Cả hai đều có thể tạo ra một ngày hợp lệ. Vì vậy, chỉ thấy công cụ chuyển đổi không báo lỗi chưa đủ để kết luận ngày đã đúng.
Duy thử trên vài dòng có đặc điểm khác nhau trước. Cậu so lại kết quả với nguồn rồi mới xử lý phần còn lại. Những giá trị chưa giải thích được được giữ ở nhóm cần kiểm, không âm thầm bỏ đi để bảng trông sạch hơn.
Với cột tên khách lẫn ghi chú, cậu xem cách phân tách thực tế trước khi tách hàng loạt. Một dấu phẩy có thể nằm trong ghi chú, không nhất thiết là ranh giới cố định. Quy tắc chỉ đúng với vài dòng đầu sẽ gây khó nếu dùng cho cả bảng dài.
Xem kỹ khoảng trắng và bản ghi trùng

Tên cửa hàng cũng có nhiều cách viết: “Cửa hàng A”, “CH A” và một dòng có khoảng trắng cuối tên. Duy lập danh sách giá trị để xem trước khi gộp. Cậu cần biết chúng có thật sự là cùng một điểm bán hay chỉ trông gần giống nhau.
Nếu nhóm đã có mã cửa hàng, mã đó có thể giúp đối chiếu. Nhưng vẫn phải xác nhận dữ liệu được nhập đúng. Tên và mã mâu thuẫn là một dấu hiệu cần hỏi lại nguồn, không phải lý do chọn đại cột nào tiện hơn.
Trước khi xóa trùng, Duy hỏi một dòng đang đại diện cho điều gì. Một đơn có ba sản phẩm có thể xuất hiện ở ba dòng khác nhau. Nếu chỉ giữ một dòng theo mã đơn, cậu sẽ làm mất sản phẩm dù bảng sau đó nhìn gọn và không còn mã lặp.
Giả sử nguồn xác nhận mỗi dòng là một đơn hoàn chỉnh. Hai dòng cùng mã vẫn chưa chắc là lỗi xuất lặp đơn giản. Chúng có thể là trạng thái trước và sau cập nhật. Duy so các trường liên quan rồi hỏi quy tắc chọn bản cần dùng.
Cậu không mặc định dòng trên cùng là mới nhất. Bảng có thể vừa được sắp theo tên khách, nên vị trí không còn nói lên thứ tự cập nhật. Nếu giữ một bản, ghi căn cứ đã xác nhận để người kiểm sau hiểu quyết định ấy.
Khi cần gửi vài dòng để hỏi, Duy chỉ giữ thông tin liên quan và dùng kênh phù hợp. Cách chia sẻ bảng dữ liệu vừa đủ giúp người nhận kiểm được vấn đề mà không phải nhận cả danh sách thông tin khách không cần thiết.
Đối chiếu lại sau mỗi bước lớn
Trước lúc xử lý, Duy ghi các điểm đối chiếu: số dòng, số mã đơn và số đơn theo trạng thái nếu phù hợp. Các con số này có vai trò khác nhau. Với bảng mỗi dòng là một sản phẩm, số dòng không thể được gọi luôn là số đơn.
Sau mỗi bước lớn, cậu xem chỉ số nào thay đổi và vì sao. Nếu bỏ hai dòng xuất lặp đã xác nhận, số dòng giảm là điều dự kiến. Nếu tổng tiền giảm nhưng chưa biết do đâu, Duy quay lại bước vừa làm trước khi tiếp tục xây báo cáo.
Cậu kiểm mẫu ở cả các trường hợp từng gây vướng: mã có số không đầu, ngày dễ nhầm, đơn chờ giá và đơn đủ thông tin. Chỉ nhìn vài dòng sạch ở đầu bảng dễ bỏ qua ngoại lệ. Những chỗ đã sửa đáng được đối chiếu lại với nguồn.
Khi tính tổng, Duy ghi rõ đang tính những đơn nào và phần nào còn thiếu. Nếu còn đơn chưa chốt giá, người nhận cần biết con số hiện tại chưa bao gồm phần ấy. Không nên để một tổng đẹp đứng riêng rồi giấu giới hạn ở một tab khác ít ai mở.
Nếu bảng của ba người cho ra ba kết quả, bước tiếp theo là so phạm vi và quy tắc, không vội kết luận ai tính sai. Bài vì sao cùng bảng bán hàng lại ra các con số khác nhau giúp kiểm tiếp điểm này.
Duy lưu bản đã xử lý cùng đường dẫn nguồn và những quyết định chính. Khi đồng nghiệp hỏi vì sao tổng thay đổi, cậu có thể chỉ ra đơn nào được tính và dữ liệu nào còn chờ. Bảng lúc ấy vừa dùng được, vừa có cách kiểm lại khi cần.


















Bình luận (0)
Chia sẻ ý kiến và trao đổi cùng mọi người về bài viết.