คู่มือโซลูชัน
คู่มือวางแผนสำหรับลูปการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ใน Make รวมถึงการตั้งค่า ฟิลด์ใน Jodoo เรคคอร์ดหลักฐาน และหมายเหตุการเปิดใช้งาน
เปิดคู่มือMAKE + JODOO
ใช้ Make ร่วมกับ Jodoo เพื่อดำเนินการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ ระบุประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ พร้อมบันทึกผลลัพธ์ไว้ในเรคคอร์ด Jodoo ที่ติดตามได้
วิดีโอแนะนำ
วิดีโอแสดงให้เห็นว่า Make จัดการ INV-2026-1048 จาก Atlas Packaging Co. ที่เข้าสู่เวิร์กโฟลว์พร้อมความไม่ตรงกันของยอด PO และไม่มีการยืนยันการรับสินค้า จากนั้น Jodoo จะบันทึกเรคคอร์ดสำหรับการดำเนินงาน
INV-2026-1048 จาก Atlas Packaging Co. เข้าสู่เวิร์กโฟลว์พร้อมความไม่ตรงกันของยอด PO และไม่มีการยืนยันการรับสินค้า
เวิร์กโฟลว์จะเก็บประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญไว้อย่างชัดเจน แทนการส่งกลับเป็นย่อหน้าแบบไม่เป็นโครงสร้าง
การรันที่ทดสอบแล้วจะส่งผลลัพธ์การตรวจสอบไปยัง Jodoo และรับ Jodoo data ID กลับมาจาก bridge
หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, operation count และ HTTP response ใน scenario history ได้
แอป Jodoo จัดเก็บ ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น สำหรับการตรวจสอบและติดตามงาน
สรุปเดโม
การทำงานนี้เหมาะกับทีมปฏิบัติการที่ต้องการผังสถานการณ์ที่มองเห็นได้ การทดสอบแบบ Run once และประวัติโมดูล หน้านี้จะแสดงทั้งการตั้งค่าสถานการณ์แบบภาพ การรันจริง และการเขียนข้อมูลกลับไปยัง Jodoo หลักฐานจาก HTTP module เป็นแบบมองเห็นได้: method, endpoint, body type, parsed response และสถานะการทำงานเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิดตัวแก้ไขโค้ด
Make Custom webhook รับเพย์โหลดตัวอย่าง และ HTTP module ส่งฟิลด์แบบมีโครงสร้างเข้าไปยัง Jodoo
เวิร์กโฟลว์ส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญสำหรับ INV-2026-1048
ประวัติการรันของ Make แสดงการทำงานเสร็จสิ้นของ HTTP module รายละเอียด operation และการตอบกลับ Jodoo data ID
เริ่มด้วย Custom webhook วางคำขอตัวอย่าง และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปในเนื้อหา body ของ HTTP module
สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้
Jodoo จัดเก็บเรคคอร์ดข้อยกเว้นของใบแจ้งหนี้และทำให้การดำเนินการถัดไปมองเห็นได้
การดำเนินการถัดไปที่แนะนำคือพักการชำระเงิน ขอการยืนยันการรับสินค้า และขอให้เจ้าของงบประมาณอนุมัติส่วนต่าง
ชุดเครื่องมือสรุปมีทั้งคู่มือ พิมพ์เขียวฟิลด์ของ Jodoo และสูตรการทำงานเวิร์กโฟลว์ Make
หมายเหตุการตั้งค่าแพลตฟอร์ม
โมเดลเรคคอร์ดของ Jodoo สามารถคงรูปแบบเดิมได้ แต่แต่ละแพลตฟอร์มเอเจนต์มีรูปแบบการสร้าง มุมมองการทดสอบ และการส่งต่องานสู่ระบบใช้งานจริงที่ต่างกัน
หลักฐานนี้ใช้ Run once เพื่อให้เห็น bundle ที่เข้ามาและ HTTP response ได้ชัดเจน
HTTP module ทำให้ method, URL, body type และการ parse response สามารถตรวจสอบได้
Scenario history ให้บันทึกแบบภาพของ operations ระยะเวลา และ response จากการเขียนข้อมูลกลับ
การวางแผนสำหรับโปรดักชันควรครอบคลุมความเป็นเจ้าของ webhook, routers, error handlers และการใช้ operation
หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, operation count และ HTTP response ใน scenario history ได้
หลักฐานจาก HTTP module เป็นแบบมองเห็นได้: method, endpoint, body type, parsed response และสถานะการทำงานเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิด code editor
เริ่มด้วย Custom webhook วางคำขอตัวอย่าง และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปในเนื้อหา body ของ HTTP module
ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน
ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้
ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน
ชุดเวิร์กโฟลว์
ดูคู่มือ คัดลอกสูตรการทำงานของเวิร์กโฟลว์ และใช้โมเดลฟิลด์ของ Jodoo เมื่อต้องปรับเวิร์กโฟลว์ Make
Make จัดการสถานการณ์แบบภาพ; Jodoo จัดเก็บฟิลด์การตรวจสอบข้อยกเว้นของใบแจ้งหนี้สำหรับคิวของเจ้าของงาน สถานะการตรวจสอบ และการติดตามงาน
เวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้
เริ่มการทดสอบข้อยกเว้นของใบแจ้งหนี้ด้วย INV-2026-1048 เริ่มด้วย Custom webhook วางคำขอตัวอย่าง และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปในเนื้อหา body ของ HTTP module
Make Custom webhook รับเพย์โหลดตัวอย่าง และ HTTP module ส่งฟิลด์แบบมีโครงสร้างเข้าไปยัง Jodoo
ส่ง JSON แบบมีโครงสร้างไปยัง Jodoo writeback bridge หลักฐานจาก HTTP module เป็นแบบมองเห็นได้: method, endpoint, body type, parsed response และสถานะการทำงานเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิด code editor
แสดงการรันของแพลตฟอร์มที่สำเร็จและ Jodoo data ID หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, operation count และ HTTP response ใน scenario history ได้
จัดเก็บฟิลด์สำหรับการตรวจสอบโดยเจ้าของงาน การติดตามสถานะ และการติดตามงาน ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
ลูปเวิร์กโฟลว์
Custom webhook รับหรือเริ่มการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ด้วยข้อมูลจำลองก่อน
Make ใช้คำสั่งตรวจสอบที่เจาะจงและส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ
HTTP module ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และรับ data ID กลับมา
สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้
ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน
Scenario history มีประโยชน์สำหรับ AP เพราะใบแจ้งหนี้ทดสอบแต่ละใบจะเก็บ bundle, route, operation count และรายละเอียด response ไว้ในรันแบบภาพเดียว
หลังจากได้หลักฐานแล้ว Make สามารถเพิ่ม aggregator สำหรับชุดใบแจ้งหนี้ data store สำหรับตรวจสอบใบแจ้งหนี้ซ้ำ และโมดูล Slack หรืออีเมลสำหรับเจ้าของงานข้อยกเว้นของ AP ได้
เริ่มด้วย Custom webhook วาง sample request และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปใน body ของ HTTP module
ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน
Jodoo สร้างเรคคอร์ด Invoice Approval Workflow และจัดเก็บ ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น, เหตุผลของข้อยกเว้น
ทีมตรวจสอบคิว มอบหมายความรับผิดชอบ และดำเนินการขั้นถัดไปให้เสร็จ: พักการชำระเงิน ขอการยืนยันการรับสินค้า และขอให้เจ้าของงบประมาณอนุมัติส่วนต่าง
ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
การแมปฟิลด์
| ข้อมูลจากเอเจนต์หรือแหล่งข้อมูลต้นทาง | ฟิลด์เรคคอร์ดของ Jodoo |
|---|---|
| รายละเอียดคำขอต้นทาง | ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้ |
| ฟิลด์การตัดสินใจจากการตรวจสอบ | ธงข้อยกเว้น, เหตุผลของข้อยกเว้น, สถานะการลงบัญชี, ความพร้อมในการชำระเงิน, สถานะการอนุมัติ |
| การตอบกลับของเวิร์กโฟลว์ | แพลตฟอร์มต้นทาง, ผลลัพธ์เวิร์กโฟลว์ต้นฉบับ |
สูตรการทำงานของเอเจนต์
ตรวจสอบคำขอการตรวจสอบข้อยกเว้นของใบแจ้งหนี้หนึ่งรายการ และส่งกลับฟิลด์แบบมีโครงสร้างที่ Jodoo สามารถจัดเก็บ ส่งต่อ และรายงานผลได้ เริ่มด้วย Custom webhook วาง sample request และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปใน body ของ HTTP module
ใช้บริบทตัวอย่างสำหรับ INV-2026-1048 ตัดสินใจประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ พร้อมทำให้การดำเนินการถัดไปที่แนะนำมีความเฉพาะเจาะจง สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้
ส่งออบเจ็กต์ JSON ที่คาดการณ์ได้ผ่าน HTTP module; Jodoo ควรได้รับชื่อฟิลด์เดิมทุกครั้งที่รัน Make เหมาะเมื่อทีมปฏิบัติการต้องการอธิบายการส่งต่องานด้วย canvas, filters, routers และประวัติการรันระดับโมดูล
ส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ รวมถึง source_platform, agent_confidence และผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทการตรวจสอบย้อนหลัง
ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง จัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครบ้างที่ได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจริงในโปรดักชัน
สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้ ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน Scenario history มีประโยชน์สำหรับ AP เพราะใบแจ้งหนี้ทดสอบแต่ละใบจะเก็บ bundle, route, operation count และรายละเอียด response ไว้ในรันแบบภาพเดียว หลังจากได้หลักฐานแล้ว Make สามารถเพิ่ม aggregator สำหรับชุดใบแจ้งหนี้ data store สำหรับตรวจสอบใบแจ้งหนี้ซ้ำ และโมดูล Slack หรืออีเมลสำหรับเจ้าของงานข้อยกเว้นของ AP ได้
{
"invoice_number": "INV-2026-1048",
"vendor_name": "Atlas Packaging Co.",
"invoice_amount": 18640,
"po_number": "PO-7782",
"exception_type": "ยอด PO ไม่ตรงกัน",
"hold_reason": "ยอดเงินไม่ตรงกันและยังไม่มีการยืนยันรับสินค้า",
"payment_readiness": "พักการชำระเงิน",
"approval_status": "ตรวจสอบข้อยกเว้น",
"assigned_owner": "ทีมข้อยกเว้น AP",
"budget_owner": "Maya Chen",
"recommended_resolution": "พักการชำระเงินและขออนุมัติส่วนต่าง",
"priority": "สูง"
}แอปเริ่มต้นของ Jodoo
ใช้โมเดลฟิลด์ มุมมอง และระบบอัตโนมัติเมื่อต้องปรับเวิร์กโฟลว์การตรวจสอบข้อยกเว้นของใบแจ้งหนี้สำหรับทีมของคุณ
เช็กลิสต์ก่อนเปิดใช้งาน
เอกสารอ้างอิงสำหรับการนำไปใช้
คู่มือวางแผนสำหรับลูปการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ใน Make รวมถึงการตั้งค่า ฟิลด์ใน Jodoo เรคคอร์ดหลักฐาน และหมายเหตุการเปิดใช้งาน
เปิดคู่มือโมเดลฟิลด์ของ Jodoo มุมมองที่แนะนำ และแนวคิดระบบอัตโนมัติสำหรับปรับใช้ Invoice Approval Workflow
เปิดพิมพ์เขียวการตั้งค่า Make ข้อกำหนดผลลัพธ์ หมายเหตุ endpoint และสูตรการทดสอบที่ใช้กับหลักฐานการเขียนข้อมูลกลับนี้
เปิดสูตรการทำงานเวิร์กโฟลว์
Make จัดการสถานการณ์แบบภาพ ส่วน Jodoo เก็บเรคคอร์ดที่ทีมสามารถกรอง มอบหมาย และตรวจสอบได้
Custom webhook รับหรือเริ่มการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ด้วยข้อมูลจำลองก่อน
Make ใช้คำสั่งตรวจสอบที่เจาะจงและส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ
HTTP module ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และรับ data ID กลับมา
สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้
ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน
Scenario history มีประโยชน์สำหรับ AP เพราะใบแจ้งหนี้ทดสอบแต่ละใบจะเก็บ bundle, route, operation count และรายละเอียด response ไว้ในรันแบบภาพเดียว
หลังจากได้หลักฐานแล้ว Make สามารถเพิ่ม aggregator สำหรับชุดใบแจ้งหนี้ data store สำหรับตรวจสอบใบแจ้งหนี้ซ้ำ และโมดูล Slack หรืออีเมลสำหรับเจ้าของงานข้อยกเว้นของ AP ได้
เริ่มด้วย Custom webhook วาง sample request และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปใน body ของ HTTP module
ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน
Jodoo สร้างเรคคอร์ด Invoice Approval Workflow และจัดเก็บ ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น, เหตุผลของข้อยกเว้น
ทีมตรวจสอบคิว มอบหมายความรับผิดชอบ และดำเนินการขั้นถัดไปให้เสร็จ: พักการชำระเงิน ขอการยืนยันการรับสินค้า และขอให้เจ้าของงบประมาณอนุมัติส่วนต่าง
ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
เรคคอร์ด Jodoo
Jodoo เก็บฟิลด์ข้อยกเว้นของใบแจ้งหนี้แบบถาวรหลังเวิร์กโฟลว์ทำงาน: ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น, เหตุผลของข้อยกเว้น
การทดสอบจริง
ภาพหน้าจอใช้ข้อมูลจำลอง และแสดงการตั้งค่า Make การรันที่สำเร็จ และแถวข้อมูลใน Jodoo ที่เวิร์กโฟลว์สร้างขึ้น

Make Custom webhook รับ sample payload และ HTTP module ส่งฟิลด์แบบมีโครงสร้างเข้าไปยัง Jodoo

ประวัติการรันของ Make แสดงการทำงานเสร็จสิ้นของ HTTP module รายละเอียด operation และการตอบกลับ Jodoo data ID

การตรวจสอบข้อยกเว้นของใบแจ้งหนี้ถูกเขียนลงใน Jodoo โดยมองเห็นฟิลด์ ชื่อผู้ขาย หมายเลขใบแจ้งหนี้ วันที่ใบแจ้งหนี้ ยอดใบแจ้งหนี้ หมายเลข PO และวันครบกำหนด
FAQ
คำตอบเกี่ยวกับการใช้แพลตฟอร์มเอเจนต์ร่วมกับเรคคอร์ด เวิร์กโฟลว์ และเทมเพลตแอปของ Jodoo
ใช่ หลักฐานนี้ใช้ข้อมูลจำลอง มีการรันจริงใน Make และมีภาพหน้าจอการเขียนข้อมูลกลับไปยัง Jodoo ที่ยืนยันแล้วพร้อมบันทึกหลักฐาน
ใช้ Make เมื่อทีมปฏิบัติการต้องการ scenario canvas ที่มองเห็นได้ การทดสอบแบบ Run once และประวัติโมดูล จากนั้น Jodoo จะเก็บเรคคอร์ดแบบถาวรสำหรับการตรวจสอบและติดตามงาน
หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, operation count และ HTTP response ใน scenario history ได้ เริ่มด้วย Custom webhook วาง sample request และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปใน body ของ HTTP module สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้
Jodoo จัดเก็บ ชื่อผู้ขาย หมายเลขใบแจ้งหนี้ วันที่ใบแจ้งหนี้ ยอดใบแจ้งหนี้ หมายเลข PO วันครบกำหนด ธงข้อยกเว้น เหตุผลของข้อยกเว้น สถานะการลงบัญชี ความพร้อมในการชำระเงิน รวมถึงผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทการตรวจสอบย้อนหลัง
ได้ เริ่มจากการรันข้อมูลจำลองที่ยืนยันแล้ว จากนั้นจึงเชื่อมต่อฟอร์ม พอร์ทัล กล่องข้อความ APIs หรือระบบภายใน เมื่อสคีมาการตรวจสอบข้อยกเว้นของใบแจ้งหนี้มีความเสถียรแล้ว ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน
เวิร์กโฟลว์สามารถเตรียมฟิลด์การตัดสินใจได้ แต่เจ้าของงานควรตรวจสอบความเสี่ยงทางธุรกิจ การอนุมัติด้านการชำระเงินหรือกฎหมาย และการตัดสินใจขั้นสุดท้ายในการปฏิบัติงานต่อไป พร้อมจัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครบ้างที่ได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจริงในโปรดักชัน
ขั้นตอนถัดไป
เริ่มจากการรัน Make ที่ยืนยันผลแล้วหนึ่งครั้ง จากนั้นนำรูปแบบการเขียนข้อมูลกลับแบบเดียวกันไปใช้กับคิวการตรวจสอบที่เกี่ยวข้องและการส่งต่องานในการปฏิบัติงาน ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง