ERP ไม่รู้จัก Lock Rate
- Sathit Jittanupat
- 7 มิ.ย.
- ยาว 3 นาที
"ในระบบ ERP ที่ดี ข้อมูลต้องไม่รอจนหนี้หมดถึงค่อยรู้ว่ากำไรหรือขาดทุน"
ผมเป็นโปรแกรมเมอร์ที่มีโอกาสได้เข้าร่วมทีมวางระบบ ERP ให้กับกิจการนำเข้ารายหนึ่ง ซึ่งใช้ตั๋วสัญญาใช้เงิน (PN) และมีการ lock อัตราแลกเปลี่ยนเพื่อควบคุมความเสี่ยง
ในบทความนี้ ผมอยากบันทึกเรื่องเล่าจากประสบการณ์สด ๆ เกี่ยวกับการช่วยออกแบบเอกสารและโฟลว์ในระบบ เพื่อให้ข้อมูลกำไรขาดทุนจากอัตราแลกเปลี่ยนถูกรับรู้ "ทันเหตุการณ์" มากขึ้น และใช้วางแผนทางธุรกิจได้จริง
บริบทธุรกิจ: นำเข้าอาหารและราคาที่ต้องวางแผนล่วงหน้า
บริษัทลูกค้าเป็นผู้นำเข้าวัตถุดิบอาหาร ซึ่งต้องเสนอราคาสินค้าให้ลูกค้าล่วงหน้า และร่วมวางแผน supply chain แบบไม่ใช่แค่ซื้อมา-ขายไป การตั้งราคาขายจึงผูกกับต้นทุนอย่างใกล้ชิด
ในปีที่ผ่านมา อัตราแลกเปลี่ยนผันผวนหนักมาก ค่าเงินบาทแตะ 36–37 บาทต่อ USD ทำให้เกิดขาดทุนจากอัตราแลกเปลี่ยนเป็นจำนวนมาก ฝ่ายบริหารจึงเริ่มให้ความสำคัญกับตัวเลขนี้มากขึ้น
กระบวนการของเขาคือ
ซื้อสินค้าเป็นเงิน USD → ตั้งหนี้เป็นเจ้าหนี้การค้า → เปลี่ยนเป็นตั๋ว PN กับธนาคาร → lock ค่าเงินบาทไว้ตอนที่คิดว่าราคาดี → ชำระตั๋วเมื่อถึงกำหนด
ปัญหาในระบบ ERP เดิม
สิ่งที่ทีมวางระบบ ERP ของเราพบคือ "การ lock rate" และผลกระทบของมัน ไม่เคยถูกบันทึกไว้ในระบบ ERP เลย
ฝ่ายการเงินเก็บข้อมูลไว้ใน spreadsheet ส่วนตัว
ฝ่ายบัญชีรู้ตัวอีกที ก็ตอนที่ต้องจ่ายเงินให้ธนาคาร
ฝ่ายขายก็ใช้ต้นทุนที่ยังไม่รวมกำไร/ขาดทุนจาก rate ในการเสนอราคาขาย
ผลลัพธ์คือ:
ข้อมูลต้นทุนที่ใช้วางแผนไม่สะท้อนความจริง
รับรู้กำไร/ขาดทุนจากอัตราแลกเปลี่ยนช้ากว่าเหตุการณ์จริง 3–4 เดือน
แนวทางที่ทีมออกแบบร่วมกัน
หัวหน้าทีมวางระบบ (ซึ่งมีความรู้บัญชีและธุรกิจ trading) ได้เสนอให้เพิ่มเอกสารใหม่ในระบบ ERP ชื่อว่า EXG (Exchange Rate Gain/Loss Recognition) เพื่อใช้บันทึกการ lock rate และทำให้เกิดการบันทึกบัญชีที่เกี่ยวข้อง ณ เวลานั้นเลย
ผมมีหน้าที่ช่วยตรวจสอบว่าการออกแบบเอกสารนี้เชื่อมโยงกับระบบได้ไหม การบันทึกบัญชีสัมพันธ์กันถูกต้องหรือไม่ และดูว่าจุดไหนควรปรับระบบให้ยืดหยุ่นมากขึ้น (โดยไม่ต้องแก้โค้ดถ้าไม่จำเป็น)
ตัวอย่าง Flow และบัญชี
ลองดู Timeline นี้ครับ:
1. รับสินค้า (PT)
100,000 USD @ 34.7
Dr สต็อก 3,470,000
Cr เจ้าหนี้การค้า 3,470,000
2. แปลงเป็นตั๋ว PN (01/2025)
@ 34.2 → เกิดกำไรจากอัตราแลกเปลี่ยน
Dr เจ้าหนี้การค้า 3,470,000
Cr เจ้าหนี้ธนาคาร 3,420,000
Cr กำไรอัตราแลกเปลี่ยน 50,000
3. Lock Rate (EXG @ 33.8 ใน 02/2025)
Dr เจ้าหนี้ธนาคาร 40,000
Cr กำไรอัตราแลกเปลี่ยน 40,000
EXG ยังทำหน้าที่ "ปรับยอดหนี้สุทธิ" ของ PN ด้วย → เหลือยอดค้างชำระ 3,380,000
4. ชำระเงิน (05/2025)
Dr เจ้าหนี้ธนาคาร 3,380,000
Cr เงินฝากธนาคาร 3,380,000
ข้อดีที่เกิดขึ้นหลังเพิ่ม EXG
ฝ่ายบัญชีรับรู้ผลกำไร/ขาดทุนได้ตั้งแต่ช่วง lock rate ไม่ต้องรอถึงวันที่จ่ายตั๋ว
ฝ่ายวางแผนสามารถใช้ข้อมูลต้นทุนที่สะท้อนความเป็นจริงได้เร็วขึ้น
กระบวนการนี้ยังช่วยเพิ่มความโปร่งใส เพราะมีเอกสารควบคุมภายในเพิ่มขึ้น
ที่สำคัญคือ ระบบ ERP ที่ใช้งานอยู่รองรับการเพิ่มเล่มเอกสาร และเงื่อนไขการไหลของข้อมูลได้โดยไม่ต้องแก้โค้ดหลัก ผมในฐานะโปรแกรมเมอร์แค่มาช่วย validate logic ว่าถูกต้องไหม มากกว่าจะต้องเขียนอะไรเพิ่ม
มุมคิดในฐานะโปรแกรมเมอร์ที่ร่วมทีมวางระบบ
เคสนี้ทำให้ผมเห็นภาพชัดว่า บางปัญหาไม่ได้ต้องการ "การแก้โค้ด" แต่ต้องการ "การเข้าใจธุรกิจ" และแปลงเป็น flow ที่ระบบมีอยู่สามารถรองรับได้
นอกจากนี้ยังมีบทเรียนเล็ก ๆ สำหรับทีมที่ทำ ERP:
ถ้าผู้ใช้ต้องเก็บข้อมูลไว้ใน spreadsheet แสดงว่า ERP ยังไม่ตอบโจทย์พอ
การบันทึกบัญชีแบบ event-based (ตามเหตุการณ์จริง) ดีกว่าการรอผลลัพธ์
เอกสารที่ไม่มีผลบัญชี อาจมีความสำคัญในฐานะ "ตัวเชื่อมกระบวนการ" มากกว่าที่คิด
สรุป
ในโลกของ ERP ไม่ใช่ทุกปัญหาจะแก้ด้วยการเพิ่มฟีเจอร์ บางครั้ง สิ่งที่เราต้องการคือเอกสารกลางที่ทำให้ "ทุกฝ่ายรู้ทันกัน"
สำหรับผม เคสนี้คือหนึ่งในตัวอย่างที่ทำให้เห็นว่า การทำ ERP ที่ดีคือการหาจุดที่ "ระบบ" กับ "กระบวนการจริง" มาเจอกันได้อย่างสมดุล
หากคุณทำ ERP หรือดูแลระบบในองค์กร ลองมองหาสิ่งที่ยังอยู่นอกระบบดูครับ เพราะบางครั้งสิ่งสำคัญที่สุด… อาจยังอยู่ใน spreadsheet ของใครบางคน
จากสนทนา สู่บทความ
ผมทดลองเปลี่ยนรูปแบบการสนทนากับ AI คราวนี้ผมเป็นฝ่ายมีวัตถุดิบหรือรายละเอียดที่ตั้งใจจะเล่า แต่ขี้เกียจเรียบเรียงเป็นบทความเอง จึงวางแผนว่าจะเล่าเท่าที่คิดออก แล้วให้ Chat GPT ทำหน้าที่สัมภาษณ์ แล้วช่วยเรียบเรียงเป็นบทความ
ผลลัพธ์เป็นดังที่เห็นด้านบน สารภาพว่ายังไม่ถูกใจผมเท่าไหร่ (น่าจะทำได้ดีกว่านี้) อุตส่าห์เล่ายืดยาว ได้บทความมานิดเดียว เหมาะสำหรับคนที่ไม่ชอบอ่านอะไรยาวๆ เพราะเลือกให้ใช้โทนภาษา "ในลักษณะแชร์ความรู้จากโปรแกรมเมอร์"
ผมมีเรื่องเล่าที่อยากให้คุณช่วยเรียบเรียงออกมาเป็นบทความ เพื่อเผยแพร่ความรู้ และเป็นกรณีศึกษาเกี่ยวกับการวางระบบโปรแกรม ERP อยากให้ใช้รูปแบบของการสนทนาเพื่อรวบรวมรายละเอียดของเรื่องเล่า คุณสามารถสอบถามเพิ่มเติมในแง่มุมที่ผมอาจเล่าตกหล่น หรือคิดว่าน่าขยายความให้ชัดเจน และเมื่อผมเห็นว่ารายละเอียดเพียงพอแล้ว จะแจ้งให้คุณเขียนเป็นบทความอีกทีหนึ่ง
เหตุการณ์เกิดขึ้นเมื่อสัปดาห์ที่แล้ว ในการประชุมออนไลน์ของทีมพัฒนาและวางระบบโปรแกรม ERP ของเรา ได้รีวิวการออกแบบระบบ เพื่อช่วยกันตรวจสอบก่อนจะส่งมอบ เป็นกรณีของกิจการแห่งหนึ่ง ซึ่งนำเข้าสินค้าจากต่างประเทศ ชำระค่าสินค้าผ่านเครดิตของธนาคาร โดยออกเป็นตั๋วสัญญาใช้เงิน (PN) กับธนาคารอีกทีหนึ่ง เนื่องจากอัตราแลกเปลี่ยนแต่ละจังหวะของธุรกรรมที่เกิดขึ้นไม่แน่นอน ทางบริษัทฯ จะต้องพยายามเลือกจังหวะ lock exchange rate เพื่อชำระตั๋ว PN เงินที่ได้ประโยชน์ หากอัตราแลกเปลี่ยนที่จะใช้คืนต่ำกว่าอัตราที่เป็นหนี้ตั๋ว PN นั่นหมายความว่า บริษัทฯ จะได้กำไรจากอัตราแลกเปลี่ยน ในทางกลับกันหากต้องชำระคืนด้วยอัตราแลกเปลี่ยนที่สูงกว่า ก็จะกลายเป็นขาดทุนจากอัตราแลกเปลี่ยนเพิ่ม
การทำงานก่อนหน้านั้น ข้อมูลการ lock rate ไม่ได้บันทึกไว้ในระบบ ERP จนกว่าจะเกิดการชำระหนี้ตั๋ว PN ทำให้ขาดข้อมูลกำไรหรือขาดทุดจากอัตราแลกเปลี่ยน ที่เกิดจากตั๋ว PN ทำให้การคำนวณต้นทุนที่แท้จริงของสินค้าคลาดเคลื่อน ซึ่งมีผลต่อการวางแผนการตลาดและเสนอราคาสินค้าให้กับคู่ค้า รวมไปถึงความยากลำบากในการรวบรวมข้อมูลเพื่อวางแผนทางการเงิน
ทีมวางระบบจึงออกแบบ document flow เพิ่มเอกสารหมวด EXG เพื่อบันทึกธุรกรรม lock rate เข้าไปใน ERP เดิม ทำให้สามารถรับรู้ข้อมูลอัตราแลกเปลี่ยนตามเวลาที่เกิดเหตุการณ์จริง เมื่อบันทึกอัตราแลกเปลี่ยนที่ จะชำระคืนตั๋ว PN จะทำให้เกิดธุรกรรมทางบัญชี 2 อย่าง คือ รับรู้กำไรหรือขาดทุนของหนี้ตั๋ว PN ณ วันที่ lock rate และขณะเดียวกันยอดเจ้าหนี้ตั๋ว PN ค้างชำระ (แปลงเป็นเงินบาท) ก็จะถูกปรับปรุงด้วย
ตัวอย่างเช่น บริษัทฯ ได้รับสินค้าเมื่อเดือน 12/2024 เป็นหนี้ค่าสินค้าสกุล USD ด้วยอัตราแลกเปลี่ยน 34.7455 เมื่อชำระค่าสินค้าเดือน 1/2025 จึงเปลี่ยนเป็นตั๋ว PN กับธนาคารที่อัตรา 34.2975 เกิดกำไรอัตราแลกเปลี่ยนจังหวะแรก หลังจากนั้นทางบริษัทฯ สามารถ lock rate ของตั๋ว PN นี้ได้ที่ 33.80 เปลี่ยนเป็นหนี้เงินบาท ทำให้เกิดกำไรจากชำระหนี้ตั๋วเป็นจังหวะที่สอง
เมื่อข้อมูลการ lock rate และกำไรหรือขาดทุนที่เกิดขึ้น ถูกบันทึกอยู่ในระบบบัญชีตามเหตุการณ์จริง ทำให้สามารถคำนวณต้นทุนสินค้าสุทธิได้ตั้งแต่เดือน 1/2025 แทนที่จะรอรับรู้เมื่อจ่ายชำระหนี้ธนาคารในเดือน 5/2025 อีก 4 เดือนต่อมา
โชคดีที่การวางระบบเอกสารและบันทึกบัญชีลักษณะนี้ สามารถทำได้โดยไม่จำเป็นต้องอาศัยโปรแกรมเมอร์ดัดแปลงโปรแกรม เนื่องจากโครงสร้างโปรแกรมของเรามีความยืดหยุ่น รองรับการตั้งหมวดหรือเล่มเอกสารได้อิสระ และสามารถกำหนดเงื่อนไขทางเดินหรือการไหลของเอกสาร ว่าเชื่อมโยงมาจากไหน และส่งต่อไปไหน พร้อมกับผูกการบันทึกบัญชีอัตโนมัติ ทำให้ลดข้อผิดพลาดและตรวจสอบยอดตัวเลขต่างๆ ได้ทันที
ผมจะเริ่มต้นถามเป็นชุดๆ เพื่อช่วยดึงรายละเอียดให้ครบถ้วนและเป็นระบบ พร้อมแล้วไปเริ่มกันเลยครับ:
(คำถาม เยอะมาก)
…
โอเค ผมจะพยายามเล่าเพิ่มเติม
ลืมบอกไปว่า ผมเป็นโปรแกรมเมอร์ซึ่งประชุมร่วมกับทีมวางระบบ เพื่อช่วยตอบคำถามทางเทคนิค รวมทั้งช่วยดูว่ามีงานส่วนไหนที่หากปรับปรุงโดยดัดแปลงโปรแกรมอาจช่วยให้มีประสิทธิภาพมากกว่า หรือนำไปผนวกเป็นฟีเจอร์โปรแกรมได้ ดังนั้นข้อมูลเกี่ยวกับบริษัทฯ จึงรู้เท่าที่ทีมวางระบบบอกมาอีกทีหนึ่ง
บริษัทดังกล่าว เป็นผู้นำเข้าวัตถุดิบสำหรับผลิตอาหาร ดังนั้นจึงมีการเสนอราคาล่วงหน้า และร่วมวางแผน supply chain ให้สอดคล้องกับลูกค้าด้วย สาเหตุที่ผู้บริหารต้องการทราบกำไรขาดทุนจากอัตราแลกเปลี่ยน เนื่องจากปีที่ผ่านมา 2024 อัตราแลกเปลี่ยนมีความผันผวนมาก ช่วงต้นปีถึงกลางปี เงินบาทอ่อนค่าอยู่ที่ 36–37 ต่อ USD ทำให้เกิดผลขาดทุนอย่างมีนัยยะสำคัญ จนต้องการติดตามตัวเลขอย่างใกล้ชิด
ทีมวางระบบของเรา ประกอบด้วยหัวหน้าทีมที่มีความรู้ทางบัญชีและกลุ่มธุรกิจ trading และมีผู้ช่วยเซ็ตโปรแกรมอีก 3 คน ที่จริงแล้วไม่เคยมีประสบการณ์เกี่ยวกับธุรกิจนำเข้านี้เลย และแทบไม่รู้เรื่องของธุรกรรมทางการเงินเกี่ยวอัตราแลกเปลี่ยน ดังนั้นในช่วงแรกจึงเป็นการเรียนรู้จากผู้ใช้ ซึ่งงานเกี่ยวกับตั๋ว PN นี้เดิม มีผู้บริหารด้านการเงินท่านหนึ่งที่รับผิดชอบ ซึ่งมีระบบเฉพาะของตัวเองที่แยกต่างหาก (Spreadsheet) ซึ่งทำให้ไม่สามารถนำข้อมูลไปใช้ประมวลผลใน ERP เพื่อให้ผู้บริหารฝ่ายอื่นใช้ประโยชน์ในการวางแผน เช่น เสนอราคา
เนื่องจากการ lock rate ไม่มีเอกสารที่ใช้เป็นหลักฐานลงบัญชี ดังนั้นการทำงานของฝ่ายบัญชี จึงรับรู้เมื่อได้รับเอกสารการชำระหนี้ตั๋ว PN หรือเมื่อเรื่องจบแล้ว การออกแบบให้มีเอกสาร EXG จึงเปรียบเสมือนเพิ่มเอกสารควบคุมภายในขึ้นมา เพื่อบันทึกอัตราแลกเปลี่ยน โดยคำนวณส่วนต่างเทียบกับอัตราเมื่อตั้งหนี้ PN ทำให้เกิดการบันทึกคู่บัญชี "เจ้าหนี้ธนาคาร" และ "กำไรหรือขาดทุนอัตราแลกเปลี่ยน" ขณะเดียวกัน EXG ก็ทำหน้าที่เสมือนเป็นใบลด/เพิ่มหนี้ปรับยอดค้างชำระสุทธิของเอกสาร PN ที่ตั้งหนี้ด้วย ทำให้เมื่อบันทึกการจ่ายด้วยเอกสาร M1 จะดึงเอกสาร PN มาตัดตามยอดหนี้สุทธิได้ทันที
สรุป flow ของเอกสารเป็นดังนี้ PT - รับสินค้า เกิดเจ้าหนี้การค้า (อัตราแลกเปลี่ยน 1) PN - เปลี่ยนเจ้าหนี้การค้าเป็นเจ้าหนี้เจ้าหนี้ธนาคาร (อัตราแลกเปลี่ยน 2) EXG - lock rate เพื่อ fix ยอดหนี้เป็นเงินบาท (อัตราแลกเปลี่ยน 3) M1 - จ่ายหนี้ธนาคาร (เงินบาท)
… ผมขอสรุปและถามต่อในบางจุดเพื่อเจาะรายละเอียดให้ครบก่อนนำไปเขียนเป็นบทความ:
(คำถาม คำถาม คำถาม)
…
ผมขออธิบายการบันทึกบัญชี ตาม timeline โดยสมมติเวลา ดังนี้
12/2024 เอกสาร PT รับสินค้า 100,000 USD x rate 34.7 dr สต็อก 3,470,000 cr เจ้าหนี้การค้า 3,470,000
01/2025 เอกสาร PN แปลงเจ้าหนี้ 100,000 USD x rate 34.2 (dif 34.7 -34.2 = 0.5) dr เจ้าหนี้การค้า 3,470,000 cr เจ้าหนี้ธนาคาร 3,420,000 cr กำไรอัตราแลกเปลี่ยน 50,000
02/2025 เอกสาร EXG lock rate 100,000 USD x rate 33.8 (dif 34.2–33.8 = 0.4) dr เจ้าหนี้ธนาคาร 40,000 cr กำไรอัตราแลกเปลี่ยน 40,000
เอกสาร EXG จะ flow ไปตัดยอดค้างชำระของ PN อัตโนมัติด้วย ทำยอดค้างชำระสุทธิเป็น 3,420,000–40,000 = 3,380,000
05/2025 เอกสาร M1 จ่ายชำระตั๋ว PN dr เจ้าหนี้ธนาคาร 3,380,000 cr เงินฝากธนาคาร 3,380,000
ข้อแตกต่าง อยู่ที่การรับรู้ทางบัญชี ยอดเจ้าหนี้ธนาคาร และ ต้นทุนสต็อก ระบบเดิมกว่าจะรู้และปรับปรุงด้วยกำไรสุทธิ ได้ก็ต้องรอจนถึงเดือน 05/2025 ซึ่งถ้าเป็นตัวเลขขาดทุนอัตราแลกเปลี่ยนที่รับรู้ช้า จะกลายเป็นปัญหา (ตั้งราคาขายขาดทุน)
ความคิดเห็น