Parsing The Invoice Details

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

เป็นเช่นเดียวกับกระแสเปลี่ยนไปใช้ Server ผ่านผู้ให้บริการ Data Center ภายนอก แทนที่จะตั้งศูนย์คอมพิวเตอร์ใช้เองบริหารจัดการด้วยศักยภาพตนเอง

ตัวอย่างบริษัทที่ใช้โปรแกรม ERP แล้วมีใช้บริการภายนอก บริหารคลังสินค้าและจัดส่ง (Logistic) จึงแลกเปลี่ยนข้อมูลออเดอร์ให้ผู้ให้บริการเพื่อวางแผนการจัดส่ง ขณะที่ออกเอกสารใบส่งสินค้าจาก ERP ในนามบริษัท และหลังจากนั้นผู้ให้บริการส่งข้อมูลสถานะการจัดส่งเพื่อใช้กลับเข้าระบบเพื่อใช้ควบคุมสต็อค,การเงินและภาษีต่อไป

บริษัทอีกแห่งหนึ่ง ใช้ระบบภายนอกบริหารช่องทางขายออนไลน์ ส่งข้อมูลออเดอร์เข้ามาที่ ERP หลังจากนั้นก็ส่งต่อไปให้ระบบภายนอกที่บริหารคลังสินค้าและจัดส่ง

บริษัทแห่งที่สาม เป็นผู้นำเข้าอาหารสดจากต่างประเทศ ใช้บริการฝากสินค้า (ห้องเย็น)​ จำเป็นต้องแลกเปลี่ยนข้อมูลการเบิกและฝากสินค้า เพื่อควบคุมบริหารสต็อคระหว่างกัน เป็นเคสที่ทำให้มองเห็นปัญหา เมื่อโปรแกรมทั้งสองฝ่ายไม่สามารถคุยกันได้ ทำให้มีภาระทุกครั้งที่เบิกหรือฝากในการตรวจทานข้อมูลระหว่างกัน

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

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

แต่โลกแห่งความจริงก็ไม่ได้สวยงามขนาดนั้น บางครั้งการรับ-ส่งข้อมูลระหว่างโปรแกรม ก็มีรายละเอียดบางส่วนที่เข้ากันไม่ได้ เหมือนกับคุณมีจอที่แสดงภาพความละเอียดสูง 4K แต่โชคร้ายที่ภาพส่งมาเป็นแค่ HD หรือกลับข้างกันจอที่แสดงภาพความละเอียดต่ำ เมื่อได้รับภาพความละเอียดสูงก็ไม่สามารถแสดงได้

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

ตัวอย่าง ข้อมูลรายการจากระบบออเดอร์

ชื่อสินค้า: *ค่าจัดส่ง 
ราคา: 30
หน่วยนับ: ครั้ง
จำนวนเงิน: 30

ปรากฎว่าเมื่อนำเข้าระบบ ERP แล้วผลลัพธ์ออกมาไม่ตรง เพราะโปรแกรม ERP คำนวณทวนด้วยวิธีของตัวเองได้ยอดจำนวนเงินเป็น 0

สาเหตุมาจากวิธีคำนวณในรายการบิลของ ERP กำหนดไว้ว่า รายการที่ระบุ "หน่วยนับ" จะต้องคำนวณจาก จำนวน (quantity) คูณกับ ราคา (price) เสมอ และในกรณีนี้บังเอิญไม่มีจำนวน

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

ราคา,จำนวน และส่วนลด

เป็นข้อมูลพื้นฐานที่น้อยที่สุด ใช้คำนวณยอดเงินในบิล ใช้สูตรคำนวณง่าย ๆ 

ราคา x จำนวน = ยอดเงิน

โปรแกรมฝั่งรับข้อมูล อย่างน้อยก็ควรมีขั้นตอนตรวจสอบพิสูจน์ค่าตามสมการดังกล่าว เพื่อป้องกัน corrupted data ก่อนที่จะรับมาใช้ เป็นสมการที่หาค่าย้อนกลับหรือเติมเต็มได้ หากระบุ ยอดเงิน กับ จำนวน ก็สามารถย้อนหา ราคา ได้ แต่ข้อจำกัดของมาตรฐานจำนวนเงินทางการค้า(และบัญชี)ที่ต้องระวังคือ เราจึงมักใช้ทศนิยม 2 ตำแหน่งสำแดงในเอกสารเท่านั้น เคสที่เกิดทศนิยมเยอะๆ โปรแกรมอาจมีความรัดกุมในการคำนวณเป็น 2 ตำแหน่งไม่เท่ากัน

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

ราคา x จำนวน [ส่วนลด] → ยอดเงิน

ข้อแตกต่างเมื่อมีส่วนลดเพิ่มเข้ามาในสูตร ทำให้การคำนวณยอดเงิน ต้องเป็นทิศทางเดียวไม่ควรย้อนกลับไปเฉลี่ยราคาต่อหน่วย

โจทย์ทดสอบ

หลายครั้งเมื่อทดสอบโปรแกรม ผมจะมีคำถามเพื่อตรวจสอบว่าโปรแกรมเหล่านั้นมีวิธีคิดหรือรับมือกับเคสเหล่านี้อย่างไร

3 ชิ้น 100

"สินค้าราคา 35 บาท ต้องการขาย 3 ชิ้น 100 บาท เปิดบิลอย่างไร" 

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

• ใช้ส่วนลดยอดสุทธิ เช่น ราคา 35 บาท 3 ชิ้น ลดสุทธิ 5 บาท มักใช้กับกรณี promotion ให้ส่วนลดตามเงื่อนไข ต้องซื้อ 3 ชิ้น

• ตั้งหน่วยนับใหม่ และใช้ราคาต่อหน่วยสำหรับหน่วยนับนั้น เช่น ราคา 100 บาท หน่วยนับ ชุด(3ชิ้น) แล้วระบุจำนวน 1 ชุด มักใช้กับกรณีสินค้าที่ขายทั่วไป ด้วยหน่วยนับใหม่ แต่มีข้อเสียหากเชื่อมโยงกับระบบสต็อคและวิเคราะห์ยอดขาย จะใช้เป็น SKU ต่างกัน หรือแปลงเป็นหน่วยพื้นฐาน

• ใช้ทศนิยมลอยอย่างน้อย 4 ตำแหน่งสำหรับราคาต่อหน่วย เพื่อปัดสุทธิ 2 ตำแหน่งแล้วไม่เพี้ยน เช่น ราคา 33.3333 จำนวน 3 ชิ้น ปัญหาอยู่ที่โปรแกรมอีกฝั่งหนึ่งจะรับทศนิยมแบบนี้ได้ไหม

ค่าบริการ ที่ไม่มีจำนวน

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

• บังคับระบุจำนวนเท่ากับ 1 (คำถามต่อไปคือ มีผลกับสต็อคไหม)

• เพิ่มเงื่อนไข ถ้าไม่ระบุจำนวน ให้เอาราคามาใช้เป็นยอดเงินอัตโนมัติ

โปรแกรมที่มีระบบควบคุมสต็อคเคร่งครัดมักใช้วิธีแยกชื่อที่ตั้งไว้สำหรับสต็อคกับไม่ใช่สต็อคได้ ทำให้สามารถใช้เป็นเงื่อนไขรองรับการคำนวณที่แตกต่างกัน กรณีที่หนึ่งถึงแม้จะระบุจำนวนแต่ก็ไม่ต้องตัดสต็อค หรือกรณีที่สอง ถึงไม่ระบุจำนวนก็คำนวณยอดเงินให้ (ถ้าเป็นสินค้าไม่ระบุจำนวนต้องยอดเงินเป็น 0)

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

• "รายการที่นับไม่ได้" คือรายการที่ไม่มีหน่วยนับ หากไม่ระบุจำนวน ก็สามารถใช้ราคามาเป็นยอดเงินอัตโนมัติ

• นอกเหนือจากนั้น รายการที่ระบุจำนวน ให้คำนวณ ราคา x จำนวน ตามปกติ

แค่แจ้งราคาสินค้าเฉยๆ

คล้ายกับค่าบริการ คือ ไม่ระบุจำนวนเหมือนกัน แต่คราวนี้ไม่ต้องการให้เกิดยอดเงิน ใช้กับกรณีใบเสนอราคา (รูปแบบ Price List) หรือกรณีแจกแจงราคาของชิ้นส่วนประกอบบางอย่าง

รายการที่ไม่ใช่สต็อค

บางครั้งรายการที่มีจำนวน ไม่จำเป็นต้องหมายถึงสินค้าในสต็อค เช่น ค่าบริการ 3 ชั่วโมง คุณสมบัติของรายการประเภทนี้คือ ไม่ว่าจะระบุจำนวนหรือไม่ก็ตาม ไม่จำเป็นต้องนับเป็นสต็อคเข้าออก เราสามารถกำหนดนิยามง่ายๆ ดังนี้

• "รายการไม่ใช่สต็อค" คือ ชื่อที่ขึ้นต้นด้วย * (ดอกจัน asterisk)

ทีนี้เราย้อนกลับไปดู รายละเอียดที่ระบบ Order ส่งให้ ERP

ชื่อสินค้า: *ค่าจัดส่ง 
ราคา: 30
หน่วยนับ: ครั้ง
จำนวนเงิน: 30

จะเห็นว่าไม่ตรงกับนิยาม "รายการที่นับไม่ได้" เพราะส่งหน่วยนับมาด้วย ขณะเดียวกันชื่อสินค้านั้นขึ้นต้นด้วย * น่าจะแสดงเจตนาว่าเป็น "รายการที่ไม่ใช่สต็อค" ซึ่งอาจนับรวมถึง "รายการที่นับไม่ได้" เป็น subset ในนั้นก็ได้

ฝั่งผู้ส่งข้อมูลจึงมี 2 ทางเลือกที่จะปรับแก้ไขรายละเอียด

• หากมีหน่วยนับ ให้ระบุจำนวน 1 มาด้วย

  
  

• หรือ เอาหน่วยนับออก

ขณะเดียวกันฝั่งโปรแกรมที่รับข้อมูลก็มีทางเลือกปรับแก้เงื่อนไขการคำนวณยอดเงินให้พิจารณาละเอียดขึ้นดังนี้

• รายการที่นับไม่ได้ (ไม่มีหน่วยนับ) หรือ รายการไม่ใช่สต็อค (ชื่อขึ้นต้นด้วย * ) หากไม่ระบุจำนวน สามารถใช้ราคามาเป็นยอดเงินอัตโนมัติ

  
  

• นอกเหนือจากนั้น รายการที่ระบุจำนวน ให้คำนวณ ราคา x จำนวน ตามปกติ

หลังจากปรับใช้เงื่อนไขใหม่ ข้อมูลดังกล่าวก็สามารถ verify ผ่านได้

สินค้าที่มีแต่ราคา (ไม่คิดเงิน) 

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

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

ส่วนลด

สมมติเหตุการณ์ ผู้ซื้อดูสินค้าราคา 50 บาทแล้วถามผู้ขายว่าราคานี้ลดได้อีกไหม ผู้ขายตอบว่าลดได้ 1 บาท ผู้ซื้อตกลงซื้อ 2 โหล (24 ชิ้น) รวมเป็นเงิน 1176 บาท ลูกค้าจึงต่อรองให้ลดอีก 6 บาท เหลือ 1170 บาทถ้วน จะเห็นว่าส่วนลดเกิดขึ้น 2 จังหวะลดราคาต่อหน่วย 1 บาท แล้วลดยอดเงินรวมอีก 6 บาท

การพลิกแพลงใช้ส่วนลดเพื่อชิงความได้เปรียบมักพบเจอในธุรกิจที่แข่งขันสูง สำหรับการออกแบบโปรแกรม อาจเลือกปฏิเสธว่าทำไม่ได้ (ไม่คบกับโปรแกรมที่ใช้ส่วนลดแบบนี้) หรือพยายามหาทางว่าทำอย่างไรส่วนลดจึงสามารถครอบคลุมได้ทุกกรณี 

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

5% หมายถึง ลด 5 เปอร์เซ็นต์จากยอดสุทธิ ปกติการลดเปอร์เซ็นต์ที่ราคาต่อหน่วยกับยอดเงินสุทธิมักได้ตัวเลขไม่ต่างกัน 

5 หมายถึง ลด 5 บาทจากยอดสุทธิ (หลังคูณจำนวน)

5| หมายถึง ลด 5 บาทจากราคาต่อหน่วย (ก่อนคูณจำนวน)

10%5% หมายถึงส่วนลดหลายชั้น

หากอธิบายเชิงโครงสร้างภาษา คำสั่งส่วนลดข้างต้นไม่ต่างจากส่วนลดที่ใช้กันทั่วไป ยกเว้นสัญญลักษณ์ | ที่ใช้แยกให้ชัดเจน​(สำหรับโปรแกรม) ว่าเป็นส่วนลดที่ราคาต่อหน่วย หรือส่วนลดที่ยอดสุทธิ 

ยกเว้นภาษี

ความซับซ้อนอย่างหนึ่งที่เกี่ยวกับใบกำกับภาษี ตรงที่สินค้าบางอย่างได้รับการยกเว้นภาษี (ไม่ต้องคิด VAT กับลูกค้า) เช่น ผลิตผลทางเกษตร ผัก ผลไม้ เนื้อสัตว์ และบางครั้งอาจรวมอยู่กับรายการสินค้าอื่นในบิลเดียวกันได้ รายละเอียดที่จำเป็นอีกอย่างหนึ่งคือ การระบุรายการยกเว้นภาษี เราสามารถออกแบบโดยกำหนด notation พิเศษ {@NV} แฝงอยู่ในข้อความปกติ เช่น ชื่อสินค้า หรือ หน่วยนับ หรือ ส่วนลด 

หรือประยุกต์ใช้สำหรับ กรณีรายการที่ยกเว้นส่วนลด {@ND} ใช้กรณีให้ส่วนลดแบบทั่วทั้งบิล สามารถระบุยกเว้นสินค้าหรือบริการรายการที่ยกเว้นส่วนลดได้

อยู่ร่วมกันให้ได้

การอยู่ร่วมกันในสังคม ต้องมีกฏกติกาที่ทุกคนรับรู้และเข้าใจตรงกัน และที่สำคัญกฏกติกานั้นคนส่วนใหญ่ปฏิบัติได้ วิธีคิดของการออกแบบเพื่อใช้งานร่วมกับโปรแกรมอื่นก็เช่นเดียวกัน ทำอย่างไรจึงแลกเปลี่ยนข้อมูลระหว่างโปรแกรม โดยไม่ขึ้นอยู่กับเทคโนโลยีหรืออ้างอิงฐานข้อมูลภายในของโปรแกรมใดโปรแกรมหนึ่ง เป็นไปได้หรือไม่ที่เราจะออกแบบระดับพื้นฐานของ "สาร" ที่ต้องการสื่อ โดยกำหนด keyword หรือสัญญลักษณ์พิเศษเท่าที่จำเป็น นิยามดังกล่าวต้องไม่ซับซ้อน หรือเป็นกรณีเฉพาะเกินไป รวมทั้งไม่ควรมีโครงสร้างข้อมูลแบบแข็งที่ยึดติดจนขาดความยืดหยุ่น 

เมื่อโปรแกรมต่างยอมรับที่จะแลกเปลี่ยนข้อมูลด้วยภาษาเดียวกัน สามารถแปลภาษานั้นได้ผลลัพธ์ตรงกัน (คำนวณตัวเลขต่างๆ ได้เหมือนกัน) รวมทั้งพิสูจน์ตรวจทานได้ การผสมผสานใช้งานให้เกิดประสิทธิภาพในองค์กรก็ไม่จำเป็นต้องผูกติดอยู่กับโปรแกรมใดโปรแกรมหนึ่ง

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

ถ้าเป็นโค้ดในโปรแกรมก็คือ การสะสม if clause เพิ่มเข้ามาเรื่อยๆ จนยืดยาวรับมือกับความหลากลาย จนกว่าจะตกตะกอนพบจุดร่วมอะไรเป็น exception อะไรเป็น common rule วันนี้เริ่มจากบอกเล่าคำอธิบายวิธีตีความของตนเองออกมา ไม่กลายเป็นโปรแกรมโดดเดี่ยวที่ไม่เปิดโอกาสให้ใครคุยด้วยแบบสมัยก่อน