วิธีนำ Work Order จาก SAP เข้าระบบ Tulip (5 แนวทาง)

ภาพรวมสั้น ๆ

1. SAP API → Tulip Connector & Automation – อัตโนมัติที่สุด

2. Manual CSV Import – ง่าย เร็ว ไม่ต้องโค้ด

3. Tulip App Upload + Parser – มี UI ให้ Planner/Operator อัปโหลด

4. Microsoft Excel Connector – ดึงไฟล์จาก OneDrive/SharePoint อัตโนมัติ

5. SAP API → Ignition WebDev → Tulip – ใช้ Ignition เป็น Gateway ก่อน

ทั้ง 5 วิธีสุดท้ายจะสร้าง/อัปเดต Tulip Table “Work Order” ซึ่งถูกใช้ต่อโดย Tulip Scheduling App และระบบ OEE ใน Ignition

1) SAP API → Tulip Connector & Automation

ขั้นตอนย่อ

1. ขอ Endpoint เช่น /sap/opu/odata/sap/ZPP_WORKORDER_SRV/Orders

2. สร้าง Connector Function แบบ GET

3. สร้าง Automation (Schedule ทุก 5 นาที หรือ Webhook Trigger)

4. ใช้ “Upsert by key (WO_ID)” เพื่อเลี่ยง duplicated records

2) Manual CSV Import (Planner CSV Upload)

Tip: เพิ่ม Tulip Automation “On record created” เพื่อตรวจ duplicated WO_ID แล้วแจ้งเตือนได้

3) Tulip App Upload + Parser

ตัวอย่างโค้ด (Node.js ใน Connector Host)

const XLSX = require('xlsx');
exports.run = async ({ fileUrl }) => {
  const buf = await fetch(fileUrl).then(r => r.arrayBuffer());
  const wb = XLSX.read(buf, { type: 'buffer' });
  const json = XLSX.utils.sheet_to_json(wb.Sheets[wb.SheetNames[0]]);
  // map fields & POST /tables/work_order/records
};

4) Microsoft Excel Connector (Graph API)

ตั้ง Scope: Files.Read, offline_access เพื่อ refresh token อัตโนมัติ

5) SAP API → Ignition WebDev API → Tulip / Dashboards

สรุปข้อแนะนำ (สำหรับ Junior Dev)

1. เริ่มต้นเร็ว (Pilot) → ใช้ Method 2 หรือ 3

2. ถ้าทีม IT เปิด APIได้ → ย้ายไป Method 1 เพื่อ Automation เต็มรูปแบบ

3. หาก WO ไฟล์เก็บใน Office 365 → Method 4 เป็นตัวเลือกดี

4. ถ้า OT อยากรวมทุกอย่างผ่าน Ignition → Method 5 แต่ต้องจัดการ Sync เพิ่ม

Checklist ก่อนลงมือ

• ตกลง Schema ของ WorkOrder (Primary Key, Required Fields)

• สร้าง Staging Table ถ้าทำ Validation หลายชั้น

• ทำ Idempotent Upsert (WO_ID เป็น key)

• เตรียม Error Log & Notification channel (Email / Tulip App)

• เขียน Unit Test (File parser / API response)

ทำไม “ชุดข้อมูลจาก SAP” ต้องยืดหยุ่นตามวิธีที่ลูกค้าใช้งาน PP

(Thai explanation + English keywords)

Key idea – เราไม่ควรดึงข้อมูลจาก SAP แบบ one-size-fits-all แต่ต้อง “ปรับระดับความละเอียด (granularity)” ให้ตรงกับ business practice ของลูกค้า เพื่อไม่ให้ข้อมูลขาด / เกิน หรือสร้างภาระ mapping ที่ไม่จำเป็น

2 รูปแบบหลักที่พบในโรงงาน (SAP PP/MM)

รายการ Field ที่ “ต้องมี” และ “อาจต้องมี” ตามแต่ละรูปแบบ

⚠️ อย่าลืมถาม ลูกค้าว่าใช้ PPDS หรือ external APS ไหม—ถ้าใช้ APS แล้ว Push Schedule กลับ SAP (/PLAF) เราอาจต้องดึงจาก Planned Order แทน Production Order

วิธี Mapping เข้าระบบ Tulip

วิธีคุยกับลูกค้า / ทีม SAP

1. ถามระดับ Scheduling:

   • “Production Planning ใช้แค่ Order Header หรือใช้ Routing & Work Center ด้วย?”

   • “มี system อื่น (MES, APO, PPDS) ทำ detailed schedule ไหม?”

2. ขอดู Transaction ตัวอย่าง:

   • COOIS layout ของโรงงาน—หัวคอลัมน์ใดถูกใช้งานจริง

   • ถ้าใช้ CM25 / MF50 (capacity planning) → แนวโน้มเป็นรูปแบบ B

3. ปริมาณข้อมูล & Latency:

   • Macro: อัปเดตวันละครั้งพอ

   • Fine-schedule: ต้องการ near-real-time (เช่น ทุก 15 นาที)

4. Confirm Interface Direction:

   • One-way (SAP → Tulip) หรือ Two-way (ต้อง Confirm กลับ SAP)

สรุปสำหรับ Junior Dev

• เวลาถาม requirement อย่าเก็บแต่ชื่อฟิลด์—ต้องถามวิธีการวางแผนจริง ใน SAP

• เตรียม สอง data-model ภายใน Tulip:

  1. WorkOrder_Header (AUFNR)

  2. WorkOrder_Operation (AUFNR+VORN) – สร้างเมื่อเป็นรูปแบบ B

• เขียน mapping function ที่เลือกสร้าง Operation record ก็ต่อเมื่อ API payload มี VORN / ARBID.

• ทำ Config Flag (mode=HEADER_ONLY vs HEADER_OPS) ใน Connector เพื่อรองรับการเปลี่ยนอนาคตโดยไม่ต้องแก้โค้ดใหญ่