ทำไมราคาของชาวสวนจึงไม่ถูกคำนวณใหม่: การล็อกราคา ณ จุดรับซื้อ และ FIFO ในซอฟต์แวร์ล้ง

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

ดูเหมือนปัญหาเรื่องคน แต่จริง ๆ เป็นปัญหาของโมเดลข้อมูล simpliDepot ถูกสร้างให้ข้อโต้แย้งนี้ไม่มีอะไรให้ยึด

กฎหลัก: ราคา ณ วันรับซื้อถูก "คัดลอก" ไม่ใช่ "อ้างอิง"

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

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

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

flowchart TD
    A["ชาวสวนส่งผลไม้"] --> B["คนชั่งบันทึกน้ำหนักแยกตามเกรด"]
    B --> C["ค้นราคาตามวันรับซื้อ"]
    C -->|"ยังไม่ได้ตั้งราคา"| X["ระบบไม่ให้รับซื้อ"]
    C --> D["คัดลอกราคาต่อกิโลลงบนล็อต"]
    D --> E["ล็อตเข้าสต็อก"]
    E --> F["ใบสั่งขายดึงล็อตเก่าสุดก่อน"]
    F --> G["ใบแจ้งหนี้ผู้ซื้อและยอดจ่ายชาวสวน"]

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

ตัวเลขเงินที่แม่นยำ ไม่ใช่ floating point

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

เลขที่ไม่ชนกัน

ช่วงฤดูเก็บเกี่ยวมีหลายจุดชั่งและแคชเชียร์หลายคนทำงานพร้อมกัน สองคุณสมบัติที่สำคัญ:

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

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

การจัดสรรแบบ FIFO: ล็อตเก่าก่อน และตรงไปตรงมาเรื่องของขาด

เมื่อผู้ซื้อสั่งของ simpliDepot จัดสรรสต็อกจากล็อตเก่าสุดก่อนโดยอัตโนมัติ มีสองรายละเอียดที่สำคัญกว่าที่ฟังดู:

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

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

สต็อกและรายงานไม่มีวันคลาดเคลื่อน

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

สิ่งที่ระบบไม่ทำเอง: การรับซื้อแบบออฟไลน์

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

ไม่ใช่แค่ทุเรียน

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

บทความสองชิ้นก่อนหน้าเดินตามเส้นเรื่องนี้ From Durian Depot to Recycle Depot (ภาษาอังกฤษ) วางไปป์ไลน์เดียวกันลงบนธุรกิจรีไซเคิล รวมถึงจุดที่ต้องต่อยอด ส่วน EUDR Is Coming for Thai Rubber and Palm Oil (ภาษาอังกฤษ) พูดตรง ๆ ว่าแพลตฟอร์มยังไม่ทำอะไรบ้างในวันนี้ เช่น การเก็บพิกัดแปลงที่ดินตอนรับซื้อ

อ่านต่อ

• The Modern Durian Depot: Stop Counting Stock on Paper, Start Running a Real Business (ภาษาอังกฤษ)
• Idempotency in Payment APIs (ภาษาอังกฤษ) หลักการเดียวกันที่ไม่ให้ยอดจ่ายถูกบันทึกซ้ำ
• FarmScript: Designing a Programming Language for Chanthaburi Durian Farmers (ภาษาอังกฤษ)

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

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

ถ้ายังไม่มีใครตั้งราคาไว้ล่ะ?
ระบบไม่ให้รับซื้อจนกว่าจะมีราคาสำหรับพันธุ์และเกรดนั้น

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

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

ลองของจริง

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

หากต้องการคุยเรื่องล้งของคุณ บอกเราว่าเป็นสินค้าอะไร มีกี่ล้ง และต้องการเริ่มเมื่อไร เราจะส่งข้อเสนอที่กำหนดขอบเขตแล้วภายใน 48 ชั่วโมงที่ hello@simplico.net