Transforming Shopee's Tabular Model Data into Document Model Data

Sathit Jittanupat
26 ก.ค. 2567
ยาว 2 นาที

อัปเดตเมื่อ 27 ส.ค. 2567

อีคอมเมิร์ชแพลตฟอร์มช่วยตัดตอนงานขาย (เสนอราคาและคอนเฟิร์มออเดอร์) การชำระค่าสินค้า (ลูกหนี้) และการตลาด (วิเคราะห์ลูกค้า จัดแคมเปญและโฆษณา)

แต่แพลตฟอร์มไม่ครอบคลุมงานบัญชีและภาษี (รวมทั้งสต็อคด้วย) ได้แต่สรุปข้อมูลขั้นต้นเฉพาะส่วนที่ตนมี ให้ผู้ขายนำไปบันทึกเข้าระบบบัญชีของตนเอง

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

หากขายผ่านแพลตฟอร์มเติบโตมากขึ้น หมายถึงปริมาณงานเบื้องหลังที่ต้องอินพุตเข้าระบบบัญชีมากขึ้น โอกาสของความผิดพลาดของมนุษย์ (human error) ก็มากขึ้นตามไปด้วย

ความท้าทายอยู่ที่พยายามหาวิธีการนำข้อมูลจากแพลตฟอร์มมาเข้าระบบบัญชี ที่สะดวกรวดเร็วและผิดพลาดน้อย

กระบวนการนำข้อมูลธุรกรรมจากระบบหนึ่ง (อีคอมเมิร์ช) เข้าสู่อีกระบบ (บัญชี) สามารถเลือกทำได้หลายวิธี ขึ้นอยู่กับความเหมาะสม

แรงงานมนุษย์ จ้างพนักงานเพิ่มหรือใช้แรงงานที่มีอยู่แล้วป้อนข้อมูล เป็นวิธีพื้นฐานที่เริ่มได้ง่ายที่สุด ข้อจำกัดอยู่ที่ขีดความสามารถรองรับปริมาณงานจึง scale up ไม่ได้มาก หากปริมาณงานเพิ่มขึ้นอย่างรวดเร็วก็อาจทำไม่ทัน
Robotic Process Automation (RPA) ใช้ระบบอัตโนมัติเลียนแบบการป้อนข้อมูลของมนุษย์ ต้องอาศัยทักษะการจัดระบบข้อมูลส่วนที่เป็นอินพุตเตรียมไว้ก่อน แล้วสร้างสคริปต์ให้ Robot อ่านข้อมูลนั้นมาป้อนผ่านหน้าจอโปรแกรมเลียนแบบการกดคีย์บอร์ดหรือคลิกเมาส์ของมนุษย์นั่นเอง ข้อดีของวิธีการนี้อยู่ที่ไม่ต้องปรับแก้ไขโปรแกรมที่ใช้งานอยู่เดิม ต้องอาศัยทักษะ "นักจัดการข้อมูล" จัดโครงสร้างข้อมูลที่จะใช้อินพุต และทักษะ "นักพัฒนา RPA" สร้างสคริปต์ตามกลไกการทำงานและ User Interface ของโปรแกรมที่จะใช้
Electronic Data Interchange (EDI) โปรแกรมรุ่นใหม่จะมี API หรือมาตรฐานการส่งข้อมูลเข้า (Import) หรือดึงข้อมูลออก (Export) เป็นการต่อท่อตรงแลกเปลี่ยนข้อมูลระหว่างโปรแกรม โดยไม่ต้องอาศัย User Interface หรือการป้อนข้อมูลทางหน้าจอ ขณะเดียวกันไม่ต้องขั้นเจาะดาต้าเบสหาทางอ่านหรือเขียนข้อมูลตรงๆ โดยไม่ผ่านโปรแกรม วิธีการนี้ต้องอาศัยทักษะ "นักจัดการข้อมูล" แปลงโครงสร้างข้อมูลที่ดึงออกมาให้ตรงกับมาตรฐานของโปรแกรมที่จะส่งเข้าไป

Shopee Seller's Orders

Shopee เป็นแพลตฟอร์มอีคอมเมิร์ชอันดับต้นของประเทศไทย ระบบจัดการร้านค้าที่เรียกว่า Seller Center สามารถดาวน์โหลดข้อมูลคำสั่งซื้อของร้านออกมาเป็นไฟล์ Excel (xlsx) เพื่อนำไปใช้อินพุตเข้าโปรแกรมระบบบัญชีได้

ความมหัศจรรย์อยู่ที่ตารางข้อมูลคำสั่งซื้อของ Shopee ทำให้ไม่ง่ายที่จะนำไปใช้อินพุตไม่ว่าด้วยวิธีไหน จะพิมพ์ออกมาเป็นกระดาษหรือเปิดดูบนจอแล้วใช้คนป้อนข้อมูล หรือแม้กระทั่งการตัดต่อปรับเปลี่ยนตารางเพื่อใช้กับ RPA หรือ EDI ก็ท้าทายฝีมือ นอกจากจะอาศัย "นักจัดการข้อมูล" แปลงให้อยู่ในรูปแบบที่สะดวกใช้

ตัวอย่างข้อมูลออเดอร์ที่มีปัญหา

เมื่อมีรายการสินค้ามากกว่า 1 รายการ ทำให้จำเป็นต้องกระจายแถว (row) ในตารางออกมาตามรายการสินค้า

ทำให้การแสดงค่าที่ต้องคำนวณในระดับ bottom line หรือท้ายบิล เช่น ส่วนลดและค่าจัดส่ง ไม่สามารถทำได้

หากไม่แสดงซ้ำซ้อนไว้ทุกแถวก็อาจทำให้เข้าใจผิด ว่าเป็นค่าที่มีผลเฉพาะบางแถว

แต่หากแสดงซ้ำซ้อนก็ทำให้การคำนวณยอดรวมตามแนวคอลัมน์ผิด

หากพยายามเฉลี่ยกระจายยอดให้แต่ละรายการก็จะอาจมีปัญหาการปัดเศษทศนิยม ทำให้รวมทุกรายการกลับมาได้ไม่เท่าเดิม

ข้อจำกัดของโครงสร้างแบบตาราง (table) ทำให้ข้อมูลแบนราบเป็น 2 มิติ ไม่สามารถใช้อธิบายธุรกรรมที่เป็นเอกสาร นอกจากจะใช้อย่างน้อย 2 ตาราง และกำหนดความสัมพันธ์เป็นแบบ One-to-Many ระหว่างหัวท้ายบิล (one) กับ รายการในบิล (many)

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

ต้องเลือกระหว่างทำให้อ่านง่ายหรือประมวลผลง่าย

ต้องเลือกระหว่างรายละเอียดระดับเอกสาร (document level) หรือระดับบรรทัดรายการ (item level)

และผลลัพธ์ของการประนีประนอมเพื่อให้พอใช้ได้ทุกอย่าง ก็ทำให้กลายเป็นตารางข้อมูลที่ซับซ้อนจนไม่มีใครใช้งานได้โดยไม่ต้องตัดต่อ clean data

Tabular vs Document Model

โครงสร้างของ Document Model สามารถเก็บข้อมูลที่มีความหนาไม่เท่ากันได้ ซึ่งก็คือส่วนรายการสินค้าในบิล ซึ่งอาจมีมากกว่า 1 รายการได้ หนึ่งหน่วยข้อมูลของบิลจึงมีรายละเอียดทั้งหมดอยู่ด้วยกัน ไม่ต้องหาทางแยกเก็บแล้วเชื่อมโยงความสัมพันธ์

ตัวอย่างข้อมูล Tabular Model มุมมองดาต้าเบสทั่วไป ควรแยกเป็น 2 ตาราง

# Table "Order"
| docno     | date       | customer  | total | discount | netamount |
| "INV0001" | 2024-07-20 | "a****"   |    30 |        3 |        27 |

# Table "Items"
| docno     | name     | price | qty | amount |
| "INV0001" | "สินค้า A" |    20 |   1 |     20 |
| "INV0001" | "สินค้า B" |    10 |   1 |     10 |

เมื่อแปลงเป็น Document Model จะอยู่ในรูปแบบ JSON ซึ่งเป็นมุมมองเหมือนกับการมองเห็นบิลทั้งใบ

{ 
  "docno": "INV0001", "date": "2024-07-20", "customer": "a****",
  "items": [
    { "name": "สินค้า A", "price": 20, "qty": 1, "amount": 20 },
    { "name": "สินค้า B", "price": 10, "qty": 1, "amount": 10 }
  ],
  "total": 30, "discount": 3, "netamount": 27
}

จาก Document Model สามารถแสดงข้อมูลแบบตาราง Hybrid Table โดยคงรูปฟิลด์ที่มีมิติย่อยให้เป็น JSON เอาไว้ดังเดิม

# Table "Order"
| docno     | date       | customer  | items_JSON       | total | discount | netamount |
| "INV0001" | 2024-07-20 | "a****"   | "[{...}, {...}]" |    30 |        3 |        27 |

ปัจจุบันนี้ดาต้าเบสหลายรุ่น เช่น PostgreSQL, Oracle DB รองรับคอลัมน์ที่เป็น JSON datatype สอดคล้องกับ Hybrid Table นี้

ข้อจำกัดจึงอยู่ที่โปรแกรมสเปรดชีต ยังไม่มีสูตรคำนวณที่ใช้กับข้อมูลที่เป็น JSON ภายใน cell ทำให้ตาราง Hybrid Table ที่มีข้อมูลบางส่วนเป็น JSON ไม่เป็นที่นิยม

Transformation

ไม่เป็นไร.. เราจะออกแบบรออนาคต

ออกแบบเครื่องมือ เอาไว้ทดสอบไอเดียกับข้อมูลจาก Shopee มาใช้กันก่อน

สร้างฟังค์ชั่นยุบตารางที่เป็น item level มาเป็น document level แปลงข้อมูลบรรทัดรายการจากคอลัมน์กลายเป็น JSON

แนวคิดคล้ายกับ pivot table ที่ยุบรายละเอียดเป็น sum หรือ count แต่อาจจะซับซ้อนกว่าตรงที่ ต้องยุบหลายคอลัมน์มารวมเป็นก้อน (object) ก่อน แล้วก็ stack ก้อนนั้นไว้ใน list (array) เสมือนรวมบรรทัดรายการอีกทีหนึ่ง

คำสั่ง

pivotFields ใช้สำหรับเลือกคอลัมน์ที่ต้องการยุบรวมกัน เมื่อค่าในคอลัมน์นั้นเหมือนกัน เช่น เลขที่คำสั่งซื้อ
pivotItems ใช้สำหรับเลือกคอลัมน์ที่ต้องการเก็บรวมกันเป็น object สำหรับข้อมูลส่วนที่เป็นบรรทัดรายการ

การทำงาน

ข้อมูลตาราง item level ส่วนที่เป็นข้อมูลซ้ำซ้อนโดยทั่วไปจะมีสองลักษณะ คือ

เบิ้ลหรือซ้ำเหมือนกันทุกบรรทัด เช่น ข้อมูลจาก Shopee
ฟันหลอ มีเฉพาะในบรรทัดแรก แล้วเว้นว่างบรรทัดถัดมา

คอลัมน์ที่ไม่ได้ระบุว่าใช้สำหรับ pivotFields และ pivotItems จะถูกตีความว่าเป็นส่วนที่อาจซ้ำซ้อนหรือฟันหลอก็ได้

คอลัมน์เหล่านี้จะใช้วิธีเช็คค่าแบบ distinct คาดหวังว่าทุกบรรทัดที่มี pivotFields ค่าเดียวกัน หากไม่ได้เว้นว่างก็ควรมีค่าเหมือนกัน มิฉะนั้นจะกลายเป็น conflict error ข้อมูลต้นทางผิดพลาด หรือคอลัมน์นั้นควรเป็น pivotItems แต่กำหนดไว้ไม่ครบถ้วนเอง

ต้นแบบที่พัฒนาตามที่ออกแบบไว้ ใช้โมดูล HCSV viewer ทำหน้าที่เป็น Transformer

เพิ่มคำสั่งประมวลผล pregen.pivotfields และ pregen.pivotitems ทำงานตามที่อธิบายก่อนหน้านั้น แล้วเอามาจัดรูปแบบตารางใหม่ตามต้องการ รวมทั้งเตรียมข้อมูลที่ใช้สำหรับส่งกลับไปบันทึกเข้าโปรแกรมของเราด้วย

จากข้อมูล Shopee (xlsx) แปลงเป็น CSV
ใช้ HCSV viewer อ่านไฟล์ csv โดยเพิ่มคำสั่ง pregen.pivotXXX แปลงข้อมูลให้เป็น document
ผลลัพธ์หลังจากแปลง เอามาแสดงผลเป็นตารางใหม่ใน HCSV จัดคอลัมน์ตามต้องการ
export ตารางใหม่นั้น เพื่อเตรียมทำ bulk import เข้าโปรแกรมอีกทีหนึ่ง