หน้าแรก / บล็อก / เงิน

วิธีแบ่งบิลเมื่อมีจานที่ไม่ได้แชร์กัน

29 สิงหาคม 2569 · อ่าน 6 นาที · Dimesum Engineering

แบ่งค่าอาหาร ฿525 เท่ากันแล้วมีคนจ่าย ฿70 สำหรับจานที่ไม่ได้กิน วิธีแก้คือค่าใช้จ่ายเดียวกับสองกฎ: ระบุคนที่กินรายการที่ไม่ได้แชร์ และให้ภาษีเป็นไปตามการบริโภค

แบ่งค่าอาหารมื้อละ ฿525 เท่ากันทุกคน แล้วมีคนหนึ่งจ่ายเกินไป ฿70 สองในสามคนกินจานซีฟู้ดราคา ฿200 ส่วนคนที่สามไม่ได้กิน แต่การหารเท่ากันกลับคิดเงินทั้งสามคนคนละ ฿175 Dimesum จัดการบิลนี้เป็นค่าใช้จ่ายรายการเดียว: หารเท่ากันในระดับบน โดยให้รายการ ฿200 ตกอยู่กับสองคนที่สั่งมันเท่านั้น

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

การแยกรายการเป็นรายละเอียดของค่าใช้จ่าย ไม่ใช่การแบ่งอีกชนิดหนึ่ง

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

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

มื้ออาหาร ฿525 ที่คนที่กินน้อยที่สุดจ่าย ฿105

Asha, Bhavna และ Chetan กินอาหารเย็น โดยหารเท่ากันในระดับบน จานที่แชร์กันรวมเป็น ฿300 จานซีฟู้ดรวมเป็น ฿200 และมีเพียง Asha กับ Bhavna ที่กินมัน ค่าบริการ 5% และ Chetan เป็นคนจ่ายทั้งหมด ฿525

Chetan จ่าย ฿525 และค้างอยู่ ฿105 ดังนั้นเขาควรได้รับคืน ฿420: ฿210 จาก Asha และ ฿210 จาก Bhavna ใครเป็นคนจ่ายเป็นเรื่องที่แยกจากใครเป็นคนค้าง การที่ผู้จ่ายเป็นคนที่แทบไม่ได้กินเลยไม่เปลี่ยนส่วนแบ่งใดๆ ซึ่งเป็นเหตุผลที่ Dimesum เก็บผู้จ่ายไว้ที่ระดับค่าใช้จ่าย และเก็บผู้ถูกกำหนดไว้ที่ระดับบรรทัด

ภาษีเป็นไปตามสิ่งที่คุณกิน ไม่ใช่ตามจำนวนคน

ส่วนของ Chetan ในค่าบริการ ฿25 คือ ฿5 ไม่ใช่ ฿8.33 ทุกการปรับถูกจัดสรรตามสัดส่วนของยอดย่อยของแต่ละคน ดังนั้นการแบ่งอาหารแบบ 200:200:100 จึงกำหนดการแบ่งค่าบริการด้วยเช่นกัน การจัดสรรตามจำนวนหัวจะคิดภาษีจาก Chetan อย่างเงียบๆ สำหรับจานที่เขาไม่เคยแตะเลย

ดังนั้นคนที่ไม่ได้สั่งอะไรเลยจึงไม่ต้องจ่ายภาษีและไม่ได้รับส่วนลด น้ำหนักที่ใช้คือยอดย่อยก่อนการปรับ ไม่ใช่ยอดสะสม ซึ่งยังช่วยป้องกันไม่ให้การปัดเศษของการปรับแต่ละครั้งสะสมทบเข้าไปในน้ำหนักของครั้งถัดไป

การปรับถูกนำมาใช้ตามลำดับ ดังนั้นส่วนลดจึงย้ายฐานของ GST

บิลที่ระบุว่า "฿1,000 ลบ 10% บวก GST 5%" จะคิด GST จาก ฿900 และบรรทัด GST เป็น ฿45 สลับสองอย่างนี้ GST จะถูกคิดจาก ฿1,000 ได้เป็น ฿50 การปรับเป็นรายการที่มีลำดับ และเปอร์เซ็นต์ถูกนำไปใช้กับยอดสะสม ณ ตำแหน่งของมันเอง ทั้งสองลำดับเป็นบิลจริง ดังนั้นรายการจึงมีลำดับ ไม่ใช่เป็นเซ็ต

การตรวจสอบสามอย่างยืนอยู่ระหว่างการพิมพ์ผิดกับเลขคณิต พูลระบุจำนวนแบบคงที่หรืออัตราเป็นเบสิสพอยต์อย่างใดอย่างหนึ่ง ไม่ใช่ทั้งสองอย่าง เพราะการเก็บทั้งสองอย่างคือการเก็บตัวเลขและที่มาของมันเอง จำนวนที่ติดลบจะถูกปฏิเสธ พร้อมข้อความแสดงข้อผิดพลาดที่ระบุ DISCOUNT เป็นวิธีเขียนการหักลด อัตราที่สูงกว่า 100,000 เบสิสพอยต์จะถูกปฏิเสธเช่นกัน ซึ่งเป็นเพดานที่ตั้งไว้สูงกว่า 10,000 เบสิสพอยต์ที่หมายถึง 100% มาก เพราะการลดร้อยเปอร์เซ็นต์เป็นส่วนลดจริง

ยอดรวมมาจากบรรทัดต่างๆ และยอดรวมที่พิมพ์เข้ามาเป็นเพียงเช็กซัม

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

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

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

ทำไม EXACT และรายการจึงถูกปฏิเสธเมื่อใช้ร่วมกัน

EXACT ระบุจำนวนสุดท้ายของสมาชิกแต่ละคน ส่วนรายการคำนวณจำนวนของสมาชิกแต่ละคน การใช้ทั้งสองอย่างพร้อมกันถูกกำหนดเกินความจำเป็น: ไม่ก็ตรงกัน ซึ่งกรณีนี้อย่างหนึ่งจะซ้ำซ้อน หรือไม่ก็ขัดแย้งกัน ซึ่งกรณีนี้ค่าใช้จ่ายมีสองคำตอบและไม่มีกฎบอกว่าอันไหนชนะ Dimesum ปฏิเสธการใช้ร่วมกันตั้งแต่ต้น แทนที่จะตัดสินด้วยกฎลำดับความสำคัญที่ไม่มีใครจำได้

EQUAL PERCENT และ SHARES ล้วนใช้ร่วมกับรายการได้ เพราะแต่ละอย่างเป็นกฎสำหรับหารต้นทุนที่แชร์กัน ไม่ใช่ชุดของจำนวนสุดท้าย

จุดที่ส่วนลดเคยทำให้เสียหนึ่งสตางค์

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

ฟังก์ชัน apportion ของเรามีข้อบกพร่องจริงตรงนี้ การหารจำนวนเต็มของ Go ตัดเศษเข้าหาศูนย์ ดังนั้นยอดรวมที่ติดลบจึงถูกปัดผิดทาง และเศษที่เหลือไม่เคยถูกแจกออกไป: −฿10.00 บนน้ำหนัก 100, 200 และ 300 กลับได้เป็น −฿9.99 หนึ่งสตางค์ที่หายไปจะทำให้บิลที่หักส่วนลดถูกต้องไม่ผ่านการตรวจสอบผลรวมของมันเอง และผู้ใช้จะถูกบอกว่าเลขคณิตของเขาผิด ตอนนี้ยอดรวมที่ติดลบถูกจัดสรรตามขนาดแล้วค่อยกลับเครื่องหมายเป็นลบ