บทความที่แล้วเล่าวิธี เชื่อม SAP Business One ด้วย Service Layer API — วันนี้จะเล่าว่า เอาการเชื่อมนั้นไปแก้ปัญหาหน้างานจริงอย่างไร: ทำเว็บแอปเปิด Purchase Request เข้า SAP B1 สำหรับงานวิศวกรรม/ซ่อมบำรุง (งานเหล็ก, รื้อเปลี่ยนรางลำเลียง)
ปัญหาที่เห็นหน้างานจริง
วิศวกรตีราคางานซ่อมออกมาเป็น BOQ (Bill of Quantities) บน Excel — รายการเหล็กรางน้ำ, เหล็กฉาก, เหล็กแผ่น พร้อมปริมาณและหน่วย เรียงเป็นหมวด `1.` `2.` และรายการย่อย `1.1` `1.2` ... หลายสิบบรรทัด
พอจะเปิด ใบขอซื้อ (PR) เข้า SAP กลับติดหล่มเดิม ๆ:
- หน้าจอ SAP มาตรฐานกรอกทีละบรรทัดช้า, ไม่เหมาะกับ 50+ รายการ
- พิมพ์ซ้ำจาก Excel เข้า ERP → พิมพ์ผิด, item code ไม่ตรง, งานซ้ำในการกระทบยอด
- หลายไฟล์หลายเวอร์ชัน → "ไม่มีใครแน่ใจว่าอันไหนล่าสุด"
- เลข PO/รูปแบบวันที่ผิด → พังตอน three-way match (PO/รับของ/ใบแจ้งหนี้) ปลายทาง
ปัญหาการ re-key จาก spreadsheet เข้า ERP เป็นต้นเหตุคลาสสิกของ error และงานกระทบยอด
BOQ ไหลเข้าสู่การจัดซื้ออย่างไร (data flow)
BOQ = เอกสารแจกแจงวัสดุ/ปริมาณ/ค่าแรงตามขอบเขตงาน ใช้ประมูล ประเมินราคา และเทียบราคา — ต่างจาก BOM (parts list ของสินค้าที่ผลิต) ตรงที่ BOQ ผูกกับ งาน/โครงการ
ในงานซ่อมบำรุง/fabrication มันคือ "แหล่งความจริงต้นทาง" ของสิ่งที่ต้องจัดซื้อ:
จุดรอยต่อที่เป็นปัญหาเล็ก ๆ กวนใจที่สุดคือ BOQ → PR — ตรงที่ยังพิมพ์มือ
"แล้ว SAP มีเครื่องมือ import มาตรฐานอยู่แล้วไม่ใช่เหรอ?" — เรื่องของ DTW
มีครับ — DTW (Data Transfer Workbench) คือเครื่องมือมาตรฐานของ SAP B1 สำหรับ import/export ข้อมูลจำนวนมากจากไฟล์ (Excel/CSV) เข้า SAP ผ่าน _template_ ที่ map ตาม business object (Items, Business Partners, และเอกสารรวมถึง PurchaseRequest) เบื้องหลังทำงานผ่าน DI API
DTW เก่งเรื่อง: โหลดข้อมูลก้อนใหญ่เป็นครั้งคราว — เช่นตอน go-live ย้ายข้อมูล, สร้าง item/BP หลายพันรายการ, validate + log ผลได้ โดยไม่ต้องเขียนโค้ด
แต่ข้อจำกัดที่ทำให้ user ทั่วไปไม่สะดวกใช้:
- เป็นเครื่องมือของ admin / consultant ไม่ใช่ end-user — ต้องเข้าใจโครง template, ชื่อ field ของ SAP, การ map `ParentKey`/`LineNum` ของเอกสาร
- ต้องรันบนเครื่องที่มี SAP B1 client + DI API (Windows) — ช่างหน้างาน/มือถือเข้าไม่ถึง
- ต้องเตรียมไฟล์ให้ตรง template เป๊ะ (รูปแบบวันที่, รหัสที่ถูกต้อง, คอลัมน์ครบ) — พลาดนิดเดียว import ล้มทั้งชุด
- ไม่มี UX ช่วยกรอก (ค้นหา item, ค่า default, validation ระหว่างกรอก) → สุดท้ายยังต้องนั่งเตรียม Excel เอง = แทบไม่ต่างจาก re-key สำหรับงาน ad-hoc รายวัน
DTW ตอบโจทย์ migration/mass-load แต่ ไม่ตอบโจทย์งาน request รายวันของ end-user ที่ต้องการ UX เฉพาะทาง + ค้นหา + default + ทำจากอุปกรณ์ไหนก็ได้ — นี่คือช่องว่างที่ webapp ผ่าน Service Layer เข้ามาเติม
ข้อจำกัดที่เอาออกไม่ได้ (และไม่ควรเอาออก)
เส้นแบ่งสำคัญของงานแบบนี้คือ "อะไรที่แอปทำได้" กับ "อะไรที่ต้องปล่อยให้ ERP คุม" — 5 ข้อนี้คือเสาที่ ถ้าถอดออกจะเสียความน่าเชื่อถือทั้งระบบ
1. SAP = system-of-record (แหล่งความจริงเดียว) — ตัวเลขสต็อก/บัญชี/เอกสารซื้อต้องอยู่ที่เดียว ถ้าแยกไปเก็บในแอปข้าง ๆ จะ _reconcile ไม่จบ_ และตรวจสอบภายนอก (ผู้สอบบัญชี/สรรพากร) ไม่ได้ แอปมีหน้าที่ _ป้อนเข้า_ ไม่ใช่ _ถือแทน_
2. License แบบ named-user (คิดตามคน) — SAP B1 คิด license ต่อผู้ใช้ ราคาต่อ user สูง ช่าง/วิศวกรส่วนใหญ่ใช้แค่ "เปิด PR" ไม่คุ้ม Professional การให้แอปคุยผ่าน service account เดียวจึงคุ้มกว่า (ดูหัวข้อ license ด้านล่าง)
3. สายอนุมัติ (Approval / governance) — วงเงิน/ลำดับผู้อนุมัติเป็น control ตาม policy บริษัทและ compliance SAP B1 มี Approval Procedures ในตัวที่ผูกกับเอกสารจริง แอปควร "ป้อนคำขอเข้าสาย" ไม่ใช่ "ตัดสายทิ้ง"
4. Business rules / data integrity ของ ERP — SAP บังคับกฎที่ทำให้เอกสารถูกต้องปลายทาง (tax code ที่ active, cost dimension, item master, posting period, three-way match) แอปต้อง _เคารพ_ กฎเหล่านี้ ไม่ใช่หาทางข้าม
5. Audit trail / traceability — ทุกเอกสารต้อง trace ได้ (ใคร/เมื่อไหร่/แก้อะไร) SAP ให้ที่ระดับเอกสาร แต่ _"ใครกดผ่านแอป"_ SAP มองไม่เห็น (เพราะ service account เดียว) จึงเป็นหน้าที่แอปต้องเติม audit ระดับตัวเองให้ครบ
แนวคิด: ไม่แทนที่ ERP แต่สร้าง "ชั้นยืดหยุ่น" ที่เขียนเข้า ERP
แทนที่จะดัด SAP ให้ทำทุกอย่าง (สะสม technical debt) หรือย้ายงานออกจาก SAP (เสีย single source of truth) — เราวางแอปเป็น ชั้นบาง ๆ ที่ own แค่ "ประสบการณ์กรอกคำขอ" แล้ว เขียนผลลัพธ์เข้า SAP ผ่าน Service Layer โดย SAP ยังเป็นความจริง
นี่คือหัวใจของแนวคิด composable / API-first ERP: ให้ ERP ถือความจริงเชิงธุรกรรม ส่วนแอปเฉพาะงาน own UX เพื่อให้ _ปรับตามวิธีทำงานจริงของทีมได้เร็ว_ โดยไม่ต้องดัด ERP
สิ่งที่แอปทำ (ยืดหยุ่น)
- นำเข้า BOQ อัตโนมัติ: อ่านไฟล์ `.xlsx` หยิบเฉพาะรายการย่อย `x.x` มาเป็นบรรทัด, ใส่ ItemCode ชั่วคราวเมื่อยังไม่รู้รหัส แล้วให้ผู้ใช้แก้รายละเอียดทีหลัง
- ค่า default นำเข้า: ตั้งคลัง/ภาษี/Factory/Department/Machine/วันที่ ครั้งเดียว ใส่ให้ทุกบรรทัด
- ค้นหาแบบมนุษย์: พิมพ์ชื่อไทยหาเครื่องจักร/สินค้า (ไม่ต้องจำรหัส) — cache ไว้ใน sqlite ไม่กระแทก SAP ทุกครั้ง
- กรอกเร็วบนอุปกรณ์ไหนก็ได้ (responsive)
สิ่งที่แอปไม่ยุ่ง (ให้ SAP คุม)
- การออกเลขเอกสาร (SAP ล็อก atomic — ยิงพร้อมกันเลขไม่ซ้ำ)
- สายอนุมัติจริง, บัญชี, สต็อก
มุมสำคัญ: license กับ "ความน่าเชื่อถือ"
จุดที่ทำให้โมเดลนี้คุ้ม: แอปคุยกับ SAP ผ่าน service account เดียว ไม่ว่าจะมีผู้ใช้แอปกี่คน — ในทางปฏิบัติ = ใช้ 1 named-user license
⚠️ ต้องยืนยันกับ SAP partner ก่อนอ้างเป็นข้อเท็จจริงเชิงสัญญา — รายละเอียดว่า "1 service account รับได้ไม่จำกัด session" มาจากแหล่งชุมชน; แต่จากการทดสอบจริงของเรา ยิง 3 PR พร้อมกันบน session เดียว DocNum ไม่ซ้ำ = concurrency ปลอดภัยระดับเทคนิค
ข้อแลก (trade-off) ที่ต้องจัดการ: เมื่อทุกใบสร้างในนาม service account เดียว SAP แยกไม่ออกว่าใครกด — accountability จึงต้อง _สร้างในชั้นแอปเอง_:
- app-login แยกผู้ใช้จริง
- audit log ระดับแอป (ใครกด, payload อะไร, สำเร็จ/ล้มเหลว, เมื่อไหร่)
- บังคับเลือก Requester เป็นพนักงานจริง (map เข้า `ReqType=Employee` ของ SAP)
นี่คือคำตอบของ "ยืดหยุ่น แต่ ตรวจสอบได้และน่าเชื่อถือ" — ความยืดหยุ่นไม่ได้แลกด้วยการเสีย control ตราบใดที่เราชดเชย accountability ที่ ERP ให้ไม่ได้ ด้วยการ audit ในแอป
Data flow ปลายทางถึงปลายทาง (ที่ระบบจริงทำ)
ข้อจำกัดที่ต้องซื่อสัตย์กับผู้ใช้: การโยงเอกสารอ้างอิง (เช่น WR→WO) แบบ "Reference Documents" ของ SAP ทำผ่าน Service Layer ไม่ได้ — ระบบจึงเก็บเลขอ้างอิงเป็น text และ _ขึ้นหมายเหตุเตือนบนฟอร์ม_ ว่าต้องเข้า SAP ทำ REF อีกครั้ง ความน่าเชื่อถือมาจากการ ไม่ซ่อนข้อจำกัด ไม่ใช่แกล้งทำเป็นทำได้
บทเรียนที่เอาไปใช้ต่อได้
1. อย่าเริ่มที่ "แอปสวย" เริ่มที่ รอยต่อข้อมูลที่เจ็บ (ตรงนี้คือ BOQ→PR)
2. ERP = ความจริง, แอป = ประสบการณ์ + accountability ที่ ERP ให้ไม่ได้
3. license เป็นทั้งข้อจำกัดและ _โอกาส_ — service account เดียวลดต้นทุน แต่ต้องชดเชยด้วย audit
4. ระบบที่ "น่าเชื่อถือ" คือระบบที่ บอกข้อจำกัดของตัวเองตรง ๆ
อยากเห็นฝั่งเทคนิคว่าเชื่อม SAP Service Layer อย่างไร (session, OData, business object, gotcha) อ่านต่อได้ที่ เชื่อม SAP Business One ด้วย Service Layer API
สนใจทำ "ชั้นยืดหยุ่น" ครอบ ERP เดิมของคุณ โดยไม่เสีย single source of truth — ทักมาคุยได้ครับ