ERP · บทที่ 4b จาก 7 · Procurement (Purchasing / Purchase-to-Pay)

Procurement: หกขั้นตอนจาก Requisition ถึง Payment

Requirements Determination → Source of Supply → Order Processing → Goods Receipt → Invoice Verification → Payment — กระบวนการที่เป็นภาพสะท้อนของ Fulfillment แทบทุกจุด เพราะบริษัทหนึ่งซื้อ คือบริษัทอีกฝั่งขาย

📚
ต่อจากบทที่ 4a — สังเคราะห์จากเอกสารบรรยาย ERP 4 และ Magal & Word บทที่ 4 (Process, Integration, Reporting)

1ภาพรวม: หกขั้นตอนของ Procurement

หกขั้นตอนหลัก
1) Requirements Determination · 2) Source of Supply Determination · 3) Order Processing · 4) Goods Receipt · 5) Invoice Verification · 6) Payment Processing — สังเกตว่าโครงสร้างนี้สมมาตรกับ Fulfillment เกือบสมบูรณ์: Requisition/PO ↔ Sales Order, Goods Receipt ↔ Delivery, Invoice Verification ↔ Billing, Payment ↔ Payment (ฝั่งตรงข้าม)

2Requirements Determination

ตัวกระตุ้นมักมาจาก Material Planning process แต่ก็มาจาก Production หรือ Plant Maintenance ได้เช่นกัน (เช่นต้องซื้อ non-stock item/บริการจากภายนอก หรือส่งชิ้นส่วนไปซ่อมภายนอกซึ่งสร้าง requirement แบบ subcontracted item) ข้อมูลที่ต้องระบุคือ item category, ปริมาณ, วันส่งมอบที่ต้องการ, และ receiving plant — สำหรับ stock item ต้องมี material number ด้วย ระบบจะดึงคำอธิบาย material group purchasing group หน่วยนับ และราคาตีมูลค่าจาก material master โดยอัตโนมัติ

ขั้นนี้ไม่มีผลทางบัญชี
ผลลัพธ์ของขั้นนี้คือ Purchase Requisition ที่มีเลขที่เอกสารเฉพาะสำหรับติดตามความคืบหน้า — สำคัญมาก: การสร้าง requisition ไม่สร้างเอกสารทางบัญชีหรือ management accounting ใด ๆ เพราะยังไม่มีข้อผูกพันทางการเงินเกิดขึ้นจริง

3Source of Supply Determination

บริษัทเลือกซัพพลายเออร์จาก Source List — ถ้ามีซัพพลายเออร์เดียวในลิสต์ ระบบผูก requisition ให้อัตโนมัติ แต่ถ้ามีหลายราย ระบบแสดงตัวเลือกให้ผู้ใช้เลือก อีกทางเลือกคือใช้ Outline Purchase Agreement ซึ่งเป็นข้อตกลงระยะยาวกับซัพพลายเออร์ แบ่งเป็นสองแบบ:

Contract
ในช่วงอายุสัญญา บริษัทสามารถ "เรียกใช้" (call off) ปริมาณหรือบริการตามที่ต้องการเป็นครั้งคราวผ่านการออก PO — PO ที่ออกภายใต้สัญญานี้เรียกว่า Contract Release Order (Release Order)
Scheduling Agreement
ปริมาณรวมของวัสดุตามข้อตกลงถูกกระจายส่งมอบตามตารางเวลาที่กำหนดไว้ล่วงหน้า (delivery schedule) — ระบุปริมาณคู่กับวันส่งมอบตามแผนแต่ละงวด

4Order Processing

Purchase Order (PO) คือการสื่อสารที่ส่งไปยังซัพพลายเออร์ ซึ่งบริษัทผูกพันตัวเองว่าจะซื้อวัสดุที่ระบุตามเงื่อนไขที่ระบุ — PO มักสร้างโดยอ้างอิงจาก requisition, RFQ (Request for Quotation), quotation, หรือแม้แต่ PO เดิม ก็สร้าง PO ใหม่ได้ (ข้อมูลส่วนใหญ่จะถูกคัดลอกมาอัตโนมัติ) หรือจะสร้างโดยไม่อ้างอิงเอกสารใดเลยก็ได้ (กรอกข้อมูลเองทั้งหมด)

PO ประกอบด้วย Header (เลขที่ PO, ซัพพลายเออร์, สกุลเงิน, วันที่, เงื่อนไขการชำระเงิน — ใช้กับทุก item ในเอกสาร) และ Item Details (รหัสวัสดุ คำอธิบาย ปริมาณ วันส่งมอบ ราคา ต่อรายการ) — งานหลักของขั้นนี้คือสร้างและส่ง PO ให้ซัพพลายเออร์ ซึ่งอาจรวมถึงการเลือกซัพพลายเออร์และยืนยันรายละเอียดโลจิสติกส์ด้วย

ความสัมพันธ์ N:M ระหว่าง Requisition กับ PO
requisition หลายใบที่ขอวัสดุเดียวกันสามารถรวมเป็น PO เดียวส่งให้ซัพพลายเออร์รายเดียว (ได้ประโยชน์จาก volume discount) หรือ requisition ใบเดียวที่มีวัสดุหลายชนิดจากซัพพลายเออร์ต่างกัน ก็แตกเป็นหลาย PO ได้ — เหมือนกับที่ Sales Order รวม/แตกจาก reference document ได้หลายแบบใน Fulfillment

5Goods Receipt

วัสดุมาพร้อม Delivery Document (หรือเรียกว่า Packing List) ที่ระบุวัสดุในการส่งมอบและ PO ที่เกี่ยวข้อง — ผู้รับใช้เอกสารนี้ตรวจสอบว่าได้รับวัสดุถูกต้องครบถ้วน PO หนึ่งใบอาจถูกส่งมอบหลายรอบ (bulky/quantity มาก) หรือหลาย PO อาจถูกส่งมารวมในการจัดส่งเดียวก็ได้

เมื่อจับคู่การส่งมอบกับ PO ระบบจะคัดลอกข้อมูลวัสดุและปริมาณจาก PO เข้าสู่ goods receipt document อัตโนมัติ (แก้ไขได้ถ้าปริมาณที่ได้รับจริงต่างจากที่สั่ง) — บริษัทรับของโดยไม่มี PO อ้างอิงก็ได้ แต่จะเสียประโยชน์เหล่านี้ไป

สถานะสต็อกที่กำหนดตอนรับของ

ค่าเริ่มต้นคือรับเข้า Unrestricted Use — แต่ถ้า material master ตั้งค่า "post to inspection stock" ไว้ (สำหรับวัสดุที่ต้องตรวจสอบคุณภาพเป็นประจำ) จะเข้าสถานะ In Quality Inspection อัตโนมัติ หรือถ้าตรวจสอบเฉพาะกรณีพิเศษ ก็ระบุสถานะได้ตอนสร้าง PO หรือตอน goods receipt เอง สุดท้าย ถ้าวัสดุไม่ตรงกับที่สั่งหรือมีปัญหา ก็กำหนดเป็น Blocked Stock ได้

Goods Receipt คือขั้นแรกของ Procurement ที่กระทบงบการเงิน (ข้อสอบชอบถาม)
บัญชี GR/IR (Goods Receipt/Invoice Receipt) ถูกเครดิต — หากเป็นการซื้อวัสดุสิ้นเปลือง (consumable) บัญชีค่าใช้จ่ายที่เกี่ยวข้อง (เช่น supplies expense) จะถูกเดบิตแทนที่จะเป็นบัญชีสต็อก สำหรับ trading goods บัญชี inventory ถูกเดบิตคู่กับ GR/IR ที่ถูกเครดิต — ระบบสร้าง Material Document (บันทึกวัสดุ ปริมาณ plant movement type) และ Accounting Document (บันทึกรายการ GL ที่ถูกกระทบ) พร้อมกัน

6Invoice Verification: หัวใจของการควบคุมการจ่ายเงิน

Three-Way Match
วิธีตรวจสอบใบแจ้งหนี้ที่พบบ่อยที่สุดคือจับคู่สามทาง (Three-Way Match) ระหว่าง Purchase Order, Goods Receipt/Delivery Document, และ Invoice เพื่อให้แน่ใจว่าปริมาณและราคาตรงกันทั้งสามเอกสาร — ทางเลือกที่เข้มงวดน้อยกว่าคือ Two-Way Match (จับคู่แค่ PO กับ Goods Receipt เท่านั้น)

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

ผลลัพธ์ทางบัญชีของ Invoice Verification
บัญชี GR/IR ถูกเดบิต (ปิดยอดที่ค้างจากตอน goods receipt) และบัญชีซัพพลายเออร์ (vendor account — subledger) ถูกเครดิตด้วยยอดเดียวกัน — เพราะ vendor account เป็น subledger จึงเกิดรายการเครดิตอัตโนมัติในบัญชี reconciliation ที่เกี่ยวข้องคือ Accounts Payable Reconciliation Account ด้วย ระบบยังอัปเดต purchase order history และเชื่อมโยงไปยัง invoice document — หากราคาที่ระบุใน invoice ต่างจากราคาใน PO ต้องอัปเดต material master ให้สะท้อนความคลาดเคลื่อนนี้ด้วย

7Payment Processing

การชำระเงินทำได้ทั้งแบบ manual หรือผ่าน Payment Program อัตโนมัติที่รันเป็นรอบ (รายวัน/รายสัปดาห์) ดึง invoice ที่อนุมัติแล้วในกรอบเวลาที่กำหนดมาสร้างการชำระเงินอัตโนมัติ ขั้นตอนประกอบด้วย: เลือกวิธีชำระและธนาคาร, ตัดสินใจว่า invoice ไหนพร้อมจ่าย, คำนวณยอดจ่าย (รวมส่วนลดถ้าจ่ายทันตามเงื่อนไข เช่น 2%/10 Net 30 หมายถึงได้ส่วนลด 2% ถ้าจ่ายภายใน 10 วัน), บันทึกเอกสารการจ่าย, และพิมพ์/ส่งช่องทางการจ่ายเงิน

ผลลัพธ์ทางบัญชีของ Payment
บัญชีธนาคาร (bank account) ถูกเครดิตด้วยยอดที่จ่าย บัญชีซัพพลายเออร์ (vendor account) และ Accounts Payable Reconciliation Account ถูกเดบิตด้วยยอดเดียวกัน — สังเกตว่าทิศทางเดบิต/เครดิตตรงข้ามกับฝั่ง Fulfillment (ที่ AR ถูกเดบิตตอนออกบิล และเครดิตตอนรับเงิน) เพราะ Procurement คือบริษัทอยู่ในบทบาท "ลูกหนี้" ไม่ใช่ "เจ้าหนี้"

8Integration กับกระบวนการอื่น

กับ Financial/Management Accounting
Vendor master ดูแลร่วมกันโดยฝ่ายจัดซื้อและฝ่ายบัญชี ขั้น goods receipt, invoice verification, payment ล้วนกระทบ GL — เมื่อซื้อวัสดุสิ้นเปลือง ใช้ controlling object เช่น cost center เพื่อเรียกเก็บค่าใช้จ่ายกับแผนกที่เกี่ยวข้อง (เชื่อมกับ CO)
กับ Material Planning, Production, Fulfillment, Asset Mgmt, Project Mgmt
กิจกรรมในกระบวนการเหล่านี้เป็นตัวสร้าง purchase requisition ที่ Procurement ประมวลผลต่อ — object ในกระบวนการเหล่านั้น (sales order, production order) จะถูกเรียกเก็บค่าใช้จ่ายจากการซื้อวัสดุนี้
กับ Inventory & Warehouse Management
Procurement เกี่ยวข้องกับการเคลื่อนย้ายวัสดุและการตรวจสอบคุณภาพ ซึ่งเป็นขอบเขตของ IWM โดยตรง

9การรายงานและ Purchasing Information System

Key Figures ที่ใช้ในรายงานฝั่งจัดซื้อครอบคลุม: ปริมาณ (quantity สั่ง/รับ), มูลค่า (value ของวัสดุที่สั่ง/รับ), และจำนวนนับ (count เช่นจำนวน PO) — ตัวอย่างข้อมูลเชิงวิเคราะห์ที่นิยมดู ได้แก่ ปริมาณวัสดุที่สั่งใน 30 วันล่าสุด, ปริมาณที่ส่งมอบโดยซัพพลายเออร์รายหนึ่งในสัปดาห์ที่ผ่านมา, จำนวน PO ที่ส่งให้ซัพพลายเออร์รายหนึ่งในเดือนที่ผ่านมา, เวลาเฉลี่ยระหว่างส่ง PO กับได้รับวัสดุต่อซัพพลายเออร์แต่ละราย (lead time performance), และมูลค่าเฉลี่ยของ PO ที่ส่งให้ซัพพลายเออร์รายหนึ่งในไตรมาสที่ผ่านมา

เช่นเดียวกับบทที่ 2 การวิเคราะห์แบ่งเป็น Standard Analysis (รายงานสำเร็จรูป เช่น เปรียบเทียบ purchasing group สองกลุ่มพร้อม drill-down ไปดูซัพพลายเออร์แต่ละราย) และ Flexible Analysis (ผู้ใช้กำหนดเองว่าจะรวม characteristic ใด เช่น vendor, material, month เข้ากับ key figure ใด เช่น order value, จำนวน item)

10เชื่อมกับศัพท์ ERP ค่ายอื่นและ Odoo

ศัพท์ SAPศัพท์ทั่วไป / Odoo
Purchase RequisitionPurchase Request (Odoo: ไม่มี object แยก มักข้ามไปสร้าง RFQ ตรง หรือใช้ module เสริม)
Purchase OrderPurchase Order (Odoo ใช้ชื่อเดียวกัน — แปลงมาจาก RFQ ที่ยืนยันแล้ว)
Goods ReceiptReceipt / Incoming Shipment (Odoo: Stock Picking ประเภท "Receipt")
Invoice Verification / Three-Way MatchBill Matching / Vendor Bill Validation (Odoo: จับคู่ PO ↔ Receipt ↔ Vendor Bill ผ่านฟีเจอร์ "Bill Control")

11ทันสมัย: Procurement ยุค 2026

แล้ว · ตำราอ้างอิง
ตอนนี้ · 2026
Invoice Verification อาศัยผู้ใช้ป้อนข้อมูลจากใบแจ้งหนี้กระดาษ/PDF ด้วยมือ
OCR + AI ดึงข้อมูลจาก invoice อัตโนมัติ (Intelligent Document Processing) และตรวจจับความผิดปกติ (เช่นราคาผิดปกติ ซัพพลายเออร์ปลอม) ก่อนถึงมือมนุษย์ ลดงาน three-way match แบบ manual ลงมาก
Source of Supply Determination อาศัย source list ที่ผูกไว้ล่วงหน้าเป็นหลัก
แพลตฟอร์ม procurement บางระบบเชื่อมกับ e-marketplace/spend-analytics เพื่อเปรียบเทียบราคาซัพพลายเออร์แบบเรียลไทม์ และแนะนำซัพพลายเออร์ใหม่ตามข้อมูลประวัติการส่งมอบ (on-time delivery score)
คำถามซ้อมสอบ
  1. เรียงลำดับหกขั้นตอนของ Procurement และอธิบายว่าแต่ละขั้นสร้างเอกสารอะไร
  2. อธิบายว่าทำไม Requisition ไม่มีผลทางบัญชี แต่ Goods Receipt มีผล
  3. อธิบาย Three-Way Match ว่าจับคู่เอกสารอะไรบ้าง และเปรียบเทียบกับ Two-Way Match
  4. เปรียบเทียบ Contract กับ Scheduling Agreement ในฐานะ Outline Purchase Agreement สองแบบ
  5. อธิบายการลงบัญชีของ Goods Receipt และ Invoice Verification ทีละขั้น พร้อมระบุว่าบัญชี GR/IR ถูกเดบิตหรือเครดิตในแต่ละขั้น
  6. อธิบายว่าทำไมทิศทางเดบิต/เครดิตของ Payment ใน Procurement จึงตรงข้ามกับ Payment ใน Fulfillment
← บทที่ 4a: Procurement — ข้อมูลพื้นฐาน บทที่ 5a: Production — Master Data →