ยอดในระบบหลังบ้านไม่ตรงกับ Excel ต้องเชื่อเลขไหน? วิธีตรวจรายงานก่อนให้ทีมแก้ Web App

Dashboard กับ Excel ยอดไม่ตรง อย่าเพิ่งแก้ฐานข้อมูลหรือเลือกเชื่อฝ่ายใดฝ่ายหนึ่ง ให้เทียบก่อนว่าเป็นยอดประเภทเดียวกัน ในช่วงวันและสถานะเดียวกันหรือไม่ แล้วแยกรายการตาม Order ID เป็นสามกลุ่ม: หายไปจากฝั่งใดฝั่งหนึ่ง, มีทั้งสองฝั่งแต่ยอดต่าง, และยอดตรงกัน วิธีนี้ช่วยชี้ว่าควรแก้นิยามรายงาน ตัวกรอง สูตร หรือข้อมูลต้นทาง โดยไม่ปรับยอดดิบเพื่อให้ผลรวมดูสวย

ตัวอย่างที่พบบ่อยคือระบบหลังบ้านรวมคำสั่งซื้อที่เพิ่งสร้าง แต่ไฟล์ Excel ของฝ่ายบัญชีนับเฉพาะคำสั่งซื้อที่ชำระแล้ว ทั้งสองยอดจึงต่างกันตั้งแต่กติกา ไม่ใช่จำเป็นต้องมีบั๊ก ลองดูตัวอย่างสาม Order และตารางตรวจผลต่างด้านล่างก่อน แล้วค่อยใช้รายการตรวจ 7 ชั้นเพื่อหาสาเหตุจริง

แนวทางนี้เหมาะกับระบบหลังบ้านที่เปิดใช้อยู่แล้ว หากกำลังย้ายข้อมูลให้ดู การเตรียมย้ายข้อมูลก่อนเปิดระบบใหม่ และถ้าเป็นข้อมูลถูกแก้ผิดให้ดู การตรวจประวัติและแก้คืนข้อมูล แทน

ตัวอย่างสมมติ: ทำไม Order 3 ใบจึงนับออกมาเป็นยอดต่างกัน

สมมติร้านหนึ่งมีข้อมูลสามรายการในวันเดียวกัน: Order A มูลค่าสินค้าก่อนส่วนลด 1,000 บาทและชำระแล้ว; Order B มูลค่า 500 บาทแต่ยังรอชำระ; Order C มูลค่า 800 บาทและยกเลิกแล้ว ตัวเลขนี้เป็นเพียง สถานการณ์สมมติ เพื่ออธิบายกติกา ไม่ใช่ข้อมูลขายของจริง

ถ้า Dashboard รวมทุก Order ที่ถูกสร้าง จะได้ 2,300 บาทจากกติกานั้น แต่ถ้า Excel กรองเฉพาะสถานะชำระแล้วจะได้ 1,000 บาท ความต่าง 1,300 บาทในตัวอย่างไม่ได้แปลว่าระบบใดบันทึกข้อมูลสูญหาย ทั้งสองระบบอาจกำลังตอบคนละคำถาม หากบริษัทต้องการ “ยอดคำสั่งซื้อที่ชำระแล้ว” ก็ต้องให้ทั้งสองฝั่งใช้กติกาเดียวกันก่อน

อีกกรณีหนึ่ง Order A มีสินค้า 2 รายการอยู่ในตาราง Item และผู้พัฒนา Join Order กับ Item แล้วนำ order_total มารวมจากทุกแถวโดยไม่ตรวจหน่วย อาจนับยอด A ซ้ำเป็น 2,000 บาทได้ ทั้งที่ Order เดิมมีมูลค่า 1,000 บาท การตรวจนี้ต้องทำโดยทีมเทคนิคอย่างปลอดภัยบนข้อมูลที่อนุญาตให้ใช้ ไม่ใช่คัดลอกฐานข้อมูลลูกค้าจริงมาไว้ในเครื่องส่วนตัวเพื่อพิสูจน์

ตัวอย่างสองแบบชี้ว่า “ผลรวมต่างกัน” อาจเกิดจากนิยามสถานะหรือรูปแบบการ Join หรือสองอย่างพร้อมกัน เจ้าของธุรกิจจึงควรขอรายชื่อ Order ID ที่อยู่ในชุดหนึ่งแต่ไม่อยู่ในอีกชุด และรายการที่ยอดต่อ ID ไม่ตรง ก่อนเปิดประเด็นว่าระบบใดถูกผิดทั้งหมด

ทำ Reconciliation Sheet เพื่อแยก “ไม่มีรายการ” กับ “ยอดรายการไม่เท่ากัน”

วิธีที่ตรวจง่ายกว่าการเทียบ Grand Total คือทำตารางตามตัวระบุที่ธุรกิจใช้จริง เช่น Order ID หรือ Invoice ID โดยเก็บข้อมูลอย่างจำเป็นและปิดบังข้อมูลลูกค้าที่ไม่เกี่ยวข้องก่อนแชร์ให้ผู้พัฒนา จากนั้นแยกผลต่างอย่างน้อยสี่ชนิด: มีเฉพาะฝั่ง A, มีเฉพาะฝั่ง B, มีทั้งคู่แต่ยอดต่าง, และมีทั้งคู่ยอดตรง

อย่าใช้คำสั่ง “Remove Duplicates” กับข้อมูลจริงโดยไม่รู้ Key ที่ควรเป็นเอกลักษณ์ เพราะการลบแถวซ้ำตามคอลัมน์ผิดอาจทำให้รายการที่ถูกต้องหาย Microsoft Power Query อธิบายว่าการเลือกชุดคอลัมน์มีผลต่อการระบุ Duplicate และไม่ได้รับประกันว่าจะเก็บแถวแรกเสมอ แนวคิดนี้เตือนให้ทีมกำหนด Identity Rule ก่อนแก้ข้อมูลทุกรูปแบบ

เมื่อพบผลต่าง ควรแยก “รายการที่ตรวจแล้ว” กับ “รายการที่รอข้อมูล” พร้อม Owner และหลักฐาน ไม่ใช่เติมศูนย์แทนค่าที่ยังหาไม่เจอ เพราะค่าศูนย์หมายถึงจำนวนที่ยืนยันว่าไม่มี ต่างจากข้อมูลที่ยังไม่พร้อมให้วัด

คำว่า “ยอดขาย” อาจหมายถึงคนละตัวเลข แม้อยู่ในเดือนเดียวกัน

ตัวเลขใน Dashboard ไม่จำเป็นต้องผิดเพียงเพราะไม่เท่ากับ Excel สมมติว่าฝ่ายขายเรียก “ยอดขาย” ว่ายอดใบสั่งซื้อที่ยืนยันแล้ว แต่บัญชีนับเฉพาะเอกสารที่ออกใบแจ้งหนี้ ส่วนผู้บริหารคาดว่าจะเห็นยอดเงินรับจริง ทั้งสามอย่างเป็นข้อมูลคนละขั้นในเส้นทางธุรกิจ แม้จะแสดงเครื่องหมายเงินบาทเหมือนกันก็ตาม

ก่อนให้ฝ่ายเทคนิคเปิด Query ให้เจ้าของรายงานตอบคำถามสั้น ๆ ว่า “รายงานนี้ใช้ตัดสินใจเรื่องอะไร?” หากต้องวัดยอดคำสั่งซื้อ ควรนิยามสถานะ Order ให้ชัด หากต้องดูเงินเข้า ต้องพิจารณารายการรับชำระและการคืนเงิน หากจะส่งข้อมูลบัญชีต้องตรวจนิยามตามนโยบายและระบบเอกสารขององค์กร ไม่ควรใช้คำว่า “รายได้” แทนทุกตัวเลขโดยไม่มีการอนุมัติ

ต้องแยกยอดรวมก่อนหรือหลังส่วนลด ภาษี ค่าจัดส่ง ค่าธรรมเนียม และการคืนเงินด้วย ร้านที่คิด “ยอดขายสินค้า” ไม่รวมค่าจัดส่ง อาจไม่ตรงกับระบบที่รวมยอดชำระของลูกค้าทั้งใบเสร็จ ความต่างนี้เป็นเรื่องนิยาม ไม่ใช่บั๊กทางเทคนิคเสมอไป หากไม่มีเจ้าของคำจำกัดความ ผู้พัฒนาอาจทำให้สองตัวเลขเท่ากันในวันนี้แต่ผิดเจตนาธุรกิจในระยะยาว

ทำ Data Contract หนึ่งหน้า ก่อนเปรียบเทียบเลขจากสองระบบ

คำว่า Data Contract ในบทความนี้หมายถึง ข้อตกลงเชิงความหมายและกติกาการวัดผล ระหว่างเจ้าของข้อมูลกับทีมทำรายงาน ไม่ใช่คำรับรองกฎหมายหรือรูปแบบไฟล์มาตรฐานที่ทุกระบบต้องใช้เหมือนกัน ให้บันทึกอย่างน้อย 8 ช่องเพื่อปิดความกำกวมก่อนเริ่มตรวจความคลาดเคลื่อน

ไม่ต้องทำเอกสารหลายสิบหน้า หากเริ่มจากหน้ารายงานหนึ่งหน้า ให้ล็อกข้อมูลเหล่านี้เฉพาะ Metric ที่กำลังตรวจ เมื่อพบว่า Excel ใช้วันที่ชำระ แต่ Dashboard ใช้วันที่สร้าง จะเห็นทันทีว่าการเทียบยอดสองชุดยังไม่มีความหมาย จนกว่าจะปรับนิยามให้ตรงหรืออธิบายว่าความต่างเป็นที่ยอมรับได้ตามวัตถุประสงค์

ไล่ตรวจผลต่าง 7 ชั้น ก่อนแตะข้อมูลจริง

1. เช็กช่วงเวลาและวันตัดรอบ

ให้เปิด Filter ทั้งสองฝั่งดูว่าคำว่า “เดือนนี้” หมายถึงช่วงเดียวกันหรือไม่ เช่น ระบบหนึ่งนับตั้งแต่วันที่ 1 เวลา 00:00 จนสิ้นวันที่สุดท้าย แต่อีกระบบใช้เวลาตัดรอบของการชำระหรือเขตเวลาเซิร์ฟเวอร์ หากข้อมูลถูกเก็บเป็นเวลา UTC แล้วแสดงเป็นเวลาไทย รายการใกล้เที่ยงคืนอาจถูกจัดคนละวันได้โดยไม่ต้องมีใครกรอกผิด

อย่าลืมตรวจว่า Filter ปลายช่วงรวมขอบเขตสุดท้ายหรือไม่ หลักการทั่วไปของการทำ Query ช่วงเวลาในระบบคือกำหนดจุดเริ่มและจุดสิ้นสุดให้ตรวจซ้ำได้ ไม่ใช้การตีความจากคำว่า “วันนี้” ในเครื่องของคนละทีมเพียงอย่างเดียว

2. เช็กสถานะที่นับเข้าและไม่เข้า

ธุรกิจจำนวนมากมีสถานะ “สร้าง”, “รอชำระ”, “ชำระแล้ว”, “ยกเลิก”, “คืนเงินบางส่วน” และ “คืนเงินครบ” หาก Excel กรองเฉพาะชำระแล้ว แต่ Dashboard รวมรายการที่เพิ่งออกใบสั่งซื้อ ยอดรวมอาจต่างกันตั้งแต่ต้น ให้ทำตารางสถานะจริงของระบบที่ระบุว่าแต่ละสถานะกระทบ Metric ใดบ้าง ไม่ใช่แก้ Query จนเลขบังเอิญเท่ากัน

ควรตรวจเหตุการณ์ที่สถานะเปลี่ยนระหว่างช่วงรายงานด้วย รายการอาจถูกสร้างเดือนก่อนและชำระเดือนนี้ เมื่อจะตอบว่าเป็นยอดของเดือนไหนต้องอ้างนิยามที่ผู้ใช้ตกลง ไม่สามารถบังคับให้ทุกแผนกใช้วันเดียวกันได้หากกำลังวัดคนละกิจกรรม

3. เช็กการนับรายการซ้ำจากการ Join ตาราง

ถ้าตาราง Orders มีหนึ่งแถวต่อคำสั่งซื้อ แต่ Order Items มีหลายแถวต่อคำสั่งซื้อ การ Join แล้วรวมยอด Order ที่ถูกทำซ้ำในทุก Item อาจทำให้ยอดสูงเกินจริง ข้อผิดพลาดแบบนี้อาจไม่เห็นเมื่อทดสอบด้วย Order ที่มีสินค้าหนึ่งชิ้น แต่ชัดเมื่อมี Order ที่หลายรายการ

Microsoft Learn แนะนำให้ตรวจ Relationship, Cardinality และทิศทาง Filter เมื่อตัวเลขรายงานผิด รวมทั้งตรวจคอลัมน์ที่ใช้เชื่อมว่าถูกคู่หรือไม่ หากทำใน SQL/BI คนละระบบ หลักคิดยังเหมือนกันคือระบุหน่วยของแต่ละแถวและตรวจว่าการเชื่อมทำให้หนึ่งแถวกลายเป็นหลายแถวโดยตั้งใจหรือไม่ อย่าลบ Duplicate แบบสุ่ม เพราะบางแถวอาจเป็นรายการสินค้าคนละชิ้นที่มีราคาเท่ากันจริง

4. เช็กส่วนลด ภาษี และการปัดเศษ

บางรายงานรวมยอดก่อนภาษี บางรายงานรวมยอดหลังภาษี หรือคำนวณส่วนลดระดับ Order กับระดับ Item ต่างกัน อีกกรณีคือระบบหนึ่งปัดเศษต่อรายการก่อนรวม ขณะที่อีกระบบรวมยอดละเอียดแล้วค่อยปัด หากไม่มีข้อตกลงเรื่องหน่วยและขั้นตอนปัด ผลลัพธ์อาจต่างกันแม้สูตรแต่ละฝั่งดูถูกต้องตามตัวเอง

เอกสาร SQL Server อธิบายว่า Decimal/Numeric มี Precision และ Scale ซึ่งการแปลงข้อมูลบางชนิดอาจปัดเศษหรือลดความแม่นได้ สำหรับการเงินควรให้ทีมกำหนดวิธีเก็บตัวเลขที่เหมาะสมกับชนิดธุรกิจและตรวจสูตรโดยเจ้าของข้อมูล ไม่ใช่ใช้ค่าทศนิยมแบบที่คาดเดาว่าพอใกล้เคียงแล้ว

5. เช็กว่าข้อมูลปลายทางรีเฟรชล่าสุดเมื่อไร

Dashboard ที่อ่านจากฐานข้อมูลสดอาจต่างกับ Excel ที่ Export เมื่อวาน ขณะเดียวกันบางระบบสร้างรายงานจาก Data Warehouse หรือ Cache ที่อัปเดตเป็นรอบ ให้แสดง Last Refresh หรือเวลาของ Snapshot อย่างชัดเจนก่อนเปรียบเทียบ หากข้อมูลคนละเวลา ไม่ควรสรุปว่าฝ่ายใดผิดจากยอดที่ไม่เท่ากัน

ในงานตัดสินใจประจำวัน ควรมีป้ายที่ผู้อ่านเข้าใจได้ เช่น “ข้อมูล ณ เวลาที่…” หากรายงานกำลัง Sync อยู่หรือมีรายการติดค้างต้องบอกสถานะนั้นด้วย ไม่ควรให้ผู้ใช้เชื่อว่าตัวเลขเรียลไทม์เพียงเพราะหน้าจอเปิดอยู่ตลอดเวลา

6. เช็กสิทธิ์และ Filter ที่ผู้ใช้แต่ละคนมองเห็น

ผู้จัดการสาขาอาจเห็นเฉพาะทีมตัวเอง แต่ Admin เห็นรวมทุกสาขา หาก Excel ได้จากบัญชีที่มีสิทธิ์กว้างกว่า ยอดรวมสองระบบอาจต่างกันตามการอนุญาตข้อมูล ไม่ใช่สูตรผิด Microsoft Learn ระบุว่า Row-Level Security และทิศทางการส่ง Filter ใน Relationship มีผลต่อผลลัพธ์รายงานได้

อย่าแก้ให้ทุกคนเห็นข้อมูลทุกสาขาเพียงเพื่อให้เลขตรงกัน ต้องกำหนดก่อนว่าผู้ดูแลแต่ละ Role ควรเห็นอะไร และทดสอบด้วยบัญชีที่มีสิทธิ์ตามจริง ไม่ใช่ใช้บัญชี Admin ทั้งหมดแล้วสรุปว่าไม่มีปัญหา

7. เช็กข้อมูลที่มาไม่ครบหรือผิดตั้งแต่ต้น

หากพบว่า Order ID บางรายการไม่มีในฐานข้อมูลรายงานหรือข้อมูลถูกแก้ภายหลัง ให้ตรวจว่ามี Pipeline นำเข้าไม่ครบ การยกเลิกรายการ รายการซ้ำ หรือการแก้ข้อมูลที่มีประวัติหรือไม่ หากต้องแก้ Record จริงให้ใช้ขั้นตอนอนุมัติและ Audit Trail ที่เหมาะสมกับความเสี่ยง ไม่ใช้คำสั่งปรับยอดรวมทับข้อมูลดิบเพื่อให้ Dashboard ดูเท่ากับ Excel

ก่อนให้ทีมพัฒนาแก้ Query ต้องตกลงเกณฑ์ตรวจรับผลใหม่

ถ้าสาเหตุคือความสัมพันธ์ของตาราง ให้ทีมแก้ในสภาพแวดล้อมทดสอบหรือกระบวนการที่ปลอดภัย แล้วตรวจด้วยชุดข้อมูลที่มีทั้ง Order หนึ่งรายการและหลายรายการ สถานะที่นับและไม่นับ รวมถึงวันที่อยู่ใกล้ขอบรอบรายงาน อย่าทดสอบเพียงตัวเลขรวมหลังแก้ เพราะสูตรอาจบังเอิญตรงจากข้อผิดพลาดสองอย่างหักล้างกันเอง

หากสาเหตุมาจากนิยาม Metric ไม่ตรง ให้เจ้าของธุรกิจอนุมัตินิยามและชื่อรายงานใหม่ก่อนเปลี่ยนโค้ด มิฉะนั้นทีมพัฒนาอาจแก้ตัวเลขให้ฝ่ายหนึ่งพอใจ แต่ทำให้ฝ่ายอื่นอ่านข้อมูลผิด สำหรับรายการที่ส่งไปบัญชีหรือระบบภายนอกแล้ว ต้องตรวจผลต่อเอกสารและการกระทบยอดตามกระบวนการขององค์กรก่อนแก้ข้อมูลย้อนหลัง

เกณฑ์ตรวจรับอย่างน้อยต้องบอกว่าคำนวณจากแถวใด สถานะใด วันตัดรอบใด ตัวเลขภาษี/ส่วนลดถูกนับอย่างไร ผู้ใช้ Role ใดเห็นข้อมูลใด และยอดรวมจากรายการที่เทียบทีละ ID ตรงกับสรุปหลังแก้หรือไม่ ถ้าข้อมูลที่ต้องใช้ยังไม่พร้อมให้ขึ้นสถานะ “รอยืนยัน” แทนการอ้างว่าทดสอบผ่านครบ

หน้ารายงานควรแสดงชื่อ Metric ที่คนใช้เข้าใจ พร้อมช่วงเวลาและเวลาอัปเดตล่าสุด ช่วยป้องกันปัญหายอดไม่ตรงกลับมาซ้ำหลังเปลี่ยนคนทำงาน หากต้องแก้ส่วน Interface, Model หรือระบบเชื่อมต่อ ผู้พัฒนาควรอธิบายผลกระทบให้คนอนุมัติเห็นก่อนปล่อยเวอร์ชันจริง

เมื่อไรควรจ้างทีมภายนอกช่วยตรวจระบบรายงาน

ถ้าทีมภายในทราบ Data Owner และมีสิทธิ์เข้าถึงข้อมูลอย่างถูกต้อง อาจเริ่มจากการตกลง Data Contract และเปรียบเทียบไม่กี่รายการได้เอง แต่เมื่อระบบมีหลายฐานข้อมูล มีการเชื่อม API หลายชั้น ใช้ Dashboard ที่มี Relationship ซับซ้อน หรือไม่มีใครอธิบายสูตรยอดขายได้ อาจต้องให้ผู้พัฒนาหรือผู้เชี่ยวชาญข้อมูลเข้ามาตรวจโดยมีขอบเขตชัดเจน

ก่อนว่าจ้าง ควรมี Brief สั้น ๆ ว่า Metric ไหนต่างกัน ต่างตั้งแต่เมื่อไร ระบบต้นทางอะไรคือเจ้าของข้อมูล มีตัวอย่าง Order ID ที่ปกปิดข้อมูลส่วนบุคคลแล้วกี่แบบ และต้องส่งมอบอะไร เช่น Source-to-Report Mapping, สูตร/Query ที่แก้, Test Case และ Reconciliation Result ไม่จำเป็นต้องเริ่มจากการรื้อ Web App ทั้งระบบ

หากธุรกิจกำลังวางแผนพัฒนา หรือปรับปรุงระบบหลังบ้าน สามารถอ่าน บริการพัฒนา Web App และระบบหลังบ้านของ Social Plus System เพื่อใช้กำหนดขอบเขตกับผู้ให้บริการ และเทียบข้อเสนอจากหลักฐานการตรวจรับ ไม่ใช่เลือกจากคำว่า “ทำ Dashboard ให้สวย” เพียงอย่างเดียว สำหรับกรณีที่รายงานถูกต้องแต่โหลดช้า ให้ดู แนวทางหาคอขวดเมื่อ Web App ช้าจากข้อมูลสะสม ซึ่งเป็นปัญหาอีกประเภทหนึ่ง

คำถามที่พบบ่อย

Excel กับระบบหลังบ้านยอดไม่ตรง ควรเชื่อระบบไหนก่อน?

ไม่ควรตัดสินจากชื่อโปรแกรม ให้ยืนยันชนิดยอด สถานะรายการ วันตัดรอบ ส่วนลด ภาษี และเวลาที่อัปเดต จากนั้นเทียบรายการตาม ID กับข้อมูลต้นทางที่ตรวจย้อนกลับได้ หากนิยามต่างกัน ทั้งสองตัวเลขอาจถูกต้องในบริบทต่างกันแต่ไม่ควรแสดงชื่อ Metric เดียวกันจนคนอ่านสับสน หากข้อมูลดิบถูกต้องแต่รายงานผิด ให้ตรวจ Model, Filter, Formula หรือ Query ก่อนแก้ Record จริง และประเมินผลต่อเอกสารหรือระบบภายนอกตามขั้นตอนขององค์กร

ยอดรวมต่างกันเล็กน้อยเพราะทศนิยม จำเป็นต้องแก้หรือไม่?

ต้องตรวจสาเหตุและข้อกำหนดของธุรกิจก่อน แม้ต่างกันเพียงเล็กน้อยก็อาจมีผลต่อเอกสารการเงิน ไม่ควรตั้ง Threshold ยอมรับเองโดยไม่มีผู้อนุมัติ ให้ดู Precision, ขั้นตอนปัดเศษ และตำแหน่งที่คำนวณส่วนลดหรือภาษีร่วมกันก่อนสรุป

พบรายการซ้ำใน Dashboard ลบทิ้งใน Excel ได้เลยหรือไม่?

ควรตรวจว่ารายการซ้ำเป็นข้อมูลต้นทางที่ผิดจริงหรือเป็นการ Join ตารางแล้วทำให้แถวขยาย อย่าลบแถวแบบสุ่ม เพราะ Order หนึ่งใบอาจมีสินค้าหลายชิ้นตามปกติ ให้กำหนด Key ที่ต้องเอกลักษณ์และทำ Reconciliation บนสำเนาที่อนุญาตก่อนแก้ข้อมูลจริง

แหล่งอ้างอิง

• Microsoft Learn. Relationship troubleshooting guidance — การตรวจ Cardinality, Filter และ Relationship เมื่อรายงานแสดงค่าผิด (เข้าถึง 4 พฤศจิกายน 2026)
• Microsoft Learn. Working with duplicate values — ข้อควรระวังในการเลือกคีย์และจัดการข้อมูลซ้ำ (เข้าถึง 4 พฤศจิกายน 2026)
• Microsoft Learn. decimal and numeric (Transact-SQL) — Precision, Scale และข้อจำกัดการแปลงชนิดตัวเลข (เข้าถึง 4 พฤศจิกายน 2026)