MAKE + JODOO

การตรวจสอบข้อยกเว้นของใบแจ้งหนี้ด้วย AI โดยใช้ Make + Jodoo

ใช้ Make ร่วมกับ Jodoo เพื่อดำเนินการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ ระบุประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ พร้อมบันทึกผลลัพธ์ไว้ในเรคคอร์ด Jodoo ที่ติดตามได้

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

วิดีโอแนะนำ

สิ่งที่เกิดขึ้นในเดโม Make

วิดีโอแสดงให้เห็นว่า Make จัดการ INV-2026-1048 จาก Atlas Packaging Co. ที่เข้าสู่เวิร์กโฟลว์พร้อมความไม่ตรงกันของยอด PO และไม่มีการยืนยันการรับสินค้า จากนั้น Jodoo จะบันทึกเรคคอร์ดสำหรับการดำเนินงาน

  1. Custom webhook รับคำขอ

    INV-2026-1048 จาก Atlas Packaging Co. เข้าสู่เวิร์กโฟลว์พร้อมความไม่ตรงกันของยอด PO และไม่มีการยืนยันการรับสินค้า

  2. Make เตรียมฟิลด์ตรวจสอบแบบมีโครงสร้าง

    เวิร์กโฟลว์จะเก็บประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญไว้อย่างชัดเจน แทนการส่งกลับเป็นย่อหน้าแบบไม่เป็นโครงสร้าง

  3. HTTP module เขียนข้อมูลไปยัง Jodoo

    การรันที่ทดสอบแล้วจะส่งผลลัพธ์การตรวจสอบไปยัง Jodoo และรับ Jodoo data ID กลับมาจาก bridge

  4. หลักฐานจาก Make ยังตรวจสอบได้

    หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, operation count และ HTTP response ใน scenario history ได้

  5. Jodoo เก็บเรคคอร์ดของทีม

    แอป Jodoo จัดเก็บ ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น สำหรับการตรวจสอบและติดตามงาน

สรุปเดโม

Make ตรวจสอบคำขอ ส่วน Jodoo ติดตามงานต่อ

การทำงานนี้เหมาะกับทีมปฏิบัติการที่ต้องการผังสถานการณ์ที่มองเห็นได้ การทดสอบแบบ Run once และประวัติโมดูล หน้านี้จะแสดงทั้งการตั้งค่าสถานการณ์แบบภาพ การรันจริง และการเขียนข้อมูลกลับไปยัง Jodoo หลักฐานจาก HTTP module เป็นแบบมองเห็นได้: method, endpoint, body type, parsed response และสถานะการทำงานเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิดตัวแก้ไขโค้ด

สถานการณ์ใน Make

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

การตัดสินใจแบบมีโครงสร้าง

เวิร์กโฟลว์ส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญสำหรับ INV-2026-1048

การรัน Make สำเร็จ

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

รายละเอียดการตั้งค่า Make

เริ่มด้วย Custom webhook วางคำขอตัวอย่าง และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปในเนื้อหา body ของ HTTP module

รายละเอียดสูตรการทำงานข้อยกเว้นของใบแจ้งหนี้

สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้

การเขียนข้อมูลกลับไปยัง Jodoo

Jodoo จัดเก็บเรคคอร์ดข้อยกเว้นของใบแจ้งหนี้และทำให้การดำเนินการถัดไปมองเห็นได้

การติดตามงานในการปฏิบัติงาน

การดำเนินการถัดไปที่แนะนำคือพักการชำระเงิน ขอการยืนยันการรับสินค้า และขอให้เจ้าของงบประมาณอนุมัติส่วนต่าง

ชุดเครื่องมือที่นำกลับใช้ซ้ำได้

ชุดเครื่องมือสรุปมีทั้งคู่มือ พิมพ์เขียวฟิลด์ของ Jodoo และสูตรการทำงานเวิร์กโฟลว์ Make

หมายเหตุการตั้งค่าแพลตฟอร์ม

สิ่งที่เฉพาะสำหรับ 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 เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง

  • สูตรการทำงานของ scenario

    สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้

  • การปรับใช้เวิร์กโฟลว์

    ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน

ชุดเวิร์กโฟลว์

สร้างลูปการตรวจสอบข้อยกเว้นของใบแจ้งหนี้แบบเดียวกัน

ดูคู่มือ คัดลอกสูตรการทำงานของเวิร์กโฟลว์ และใช้โมเดลฟิลด์ของ Jodoo เมื่อต้องปรับเวิร์กโฟลว์ Make

คู่มือโซลูชัน

สิ่งที่ทีมของคุณนำกลับมาใช้ซ้ำได้

Make จัดการสถานการณ์แบบภาพ; Jodoo จัดเก็บฟิลด์การตรวจสอบข้อยกเว้นของใบแจ้งหนี้สำหรับคิวของเจ้าของงาน สถานะการตรวจสอบ และการติดตามงาน

เวิร์กโฟลว์ธุรกิจโมเดลฟิลด์ของ Jodooพรอมป์ต์ของเอเจนต์เช็กลิสต์ก่อนเปิดใช้งาน

เวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้

เวิร์กโฟลว์ช่วยตัดสินใจ Jodoo ช่วยให้งานเดินหน้าต่อ

  1. 01

    Custom webhook

    เริ่มการทดสอบข้อยกเว้นของใบแจ้งหนี้ด้วย INV-2026-1048 เริ่มด้วย Custom webhook วางคำขอตัวอย่าง และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปในเนื้อหา body ของ HTTP module

  2. 02

    สถานการณ์ใน Make

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

  3. 03

    HTTP module

    ส่ง JSON แบบมีโครงสร้างไปยัง Jodoo writeback bridge หลักฐานจาก HTTP module เป็นแบบมองเห็นได้: method, endpoint, body type, parsed response และสถานะการทำงานเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิด code editor

  4. 04

    ผลตอบกลับของหลักฐาน

    แสดงการรันของแพลตฟอร์มที่สำเร็จและ Jodoo data ID หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, operation count และ HTTP response ใน scenario history ได้

  5. 05

    คิวใน Jodoo

    จัดเก็บฟิลด์สำหรับการตรวจสอบโดยเจ้าของงาน การติดตามสถานะ และการติดตามงาน ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง

ลูปเวิร์กโฟลว์

จากการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ใน Make สู่ Jodoo

  1. Custom webhook รับหรือเริ่มการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ด้วยข้อมูลจำลองก่อน

  2. Make ใช้คำสั่งตรวจสอบที่เจาะจงและส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ

  3. HTTP module ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และรับ data ID กลับมา

  4. สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้

  5. ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน

  6. Scenario history มีประโยชน์สำหรับ AP เพราะใบแจ้งหนี้ทดสอบแต่ละใบจะเก็บ bundle, route, operation count และรายละเอียด response ไว้ในรันแบบภาพเดียว

  7. หลังจากได้หลักฐานแล้ว Make สามารถเพิ่ม aggregator สำหรับชุดใบแจ้งหนี้ data store สำหรับตรวจสอบใบแจ้งหนี้ซ้ำ และโมดูล Slack หรืออีเมลสำหรับเจ้าของงานข้อยกเว้นของ AP ได้

  8. เริ่มด้วย Custom webhook วาง sample request และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปใน body ของ HTTP module

  9. ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน

  10. Jodoo สร้างเรคคอร์ด Invoice Approval Workflow และจัดเก็บ ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น, เหตุผลของข้อยกเว้น

  11. ทีมตรวจสอบคิว มอบหมายความรับผิดชอบ และดำเนินการขั้นถัดไปให้เสร็จ: พักการชำระเงิน ขอการยืนยันการรับสินค้า และขอให้เจ้าของงบประมาณอนุมัติส่วนต่าง

  12. ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง

  13. เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง

การแมปฟิลด์

ผลลัพธ์จากเอเจนต์กลายเป็นฟิลด์ใน Jodoo

ข้อมูลจากเอเจนต์หรือแหล่งข้อมูลต้นทางฟิลด์เรคคอร์ดของ Jodoo
รายละเอียดคำขอต้นทางชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้
ฟิลด์การตัดสินใจจากการตรวจสอบธงข้อยกเว้น, เหตุผลของข้อยกเว้น, สถานะการลงบัญชี, ความพร้อมในการชำระเงิน, สถานะการอนุมัติ
การตอบกลับของเวิร์กโฟลว์แพลตฟอร์มต้นทาง, ผลลัพธ์เวิร์กโฟลว์ต้นฉบับ

สูตรการทำงานของเอเจนต์

พรอมป์ต์และผลลัพธ์แบบมีโครงสร้าง

บทบาทของ Make

ตรวจสอบคำขอการตรวจสอบข้อยกเว้นของใบแจ้งหนี้หนึ่งรายการ และส่งกลับฟิลด์แบบมีโครงสร้างที่ 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 และผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทการตรวจสอบย้อนหลัง

การควบคุมใน Make

ตรวจสอบการใช้ 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

แอปเริ่มต้นสำหรับข้อยกเว้นของใบแจ้งหนี้

ใช้โมเดลฟิลด์ มุมมอง และระบบอัตโนมัติเมื่อต้องปรับเวิร์กโฟลว์การตรวจสอบข้อยกเว้นของใบแจ้งหนี้สำหรับทีมของคุณ

ฟิลด์ที่รวมอยู่

  • ชื่อผู้ขาย
  • หมายเลขใบแจ้งหนี้
  • วันที่ใบแจ้งหนี้
  • ยอดใบแจ้งหนี้
  • หมายเลข PO
  • วันครบกำหนด
  • ธงข้อยกเว้น
  • เหตุผลของข้อยกเว้น
  • สถานะการลงบัญชี
  • ความพร้อมในการชำระเงิน
  • สถานะการอนุมัติ
  • ผู้ตรวจสอบที่ได้รับมอบหมาย
  • เจ้าของงบประมาณ
  • แนวทางแก้ไขที่แนะนำ
  • ผลลัพธ์เวิร์กโฟลว์ต้นฉบับ

มุมมองที่แนะนำ

  • ตรวจสอบข้อยกเว้น
  • คิวพักการชำระเงิน
  • ตรวจสอบโดยเจ้าของงบประมาณ
  • พร้อมชำระเงิน
  • รายการส่งใบแจ้งหนี้ทั้งหมด

กฎระบบอัตโนมัติ

  • สร้างเรคคอร์ดใน Jodoo หลังจาก Make ส่งกลับผลลัพธ์แบบมีโครงสร้าง
  • ย้ายเรคคอร์ดที่มีลำดับความสำคัญสูงหรือเป็นข้อยกเว้นไปยังคิวของเจ้าของงานที่ถูกต้อง
  • แจ้งเจ้าของงานที่แนะนำเมื่อมีข้อมูลไม่ครบหรือมีเหตุผลที่ต้องพักชำระ
  • เก็บผลลัพธ์เวิร์กโฟลว์ต้นฉบับไว้ในบริบทการตรวจสอบย้อนหลัง

เช็กลิสต์ก่อนเปิดใช้งาน

สิ่งที่ต้องยืนยันก่อนใช้งานจริง

  • ส่งข้อมูลจำลองไปยัง Custom webhook ก่อนเปิดใช้งาน scenario
  • เปิด HTTP module อีกครั้งหลังการแก้ไข และยืนยันการแมป JSON ที่บันทึกไว้
  • ใช้ scenario history เพื่อยืนยันสถานะ operations และ response body
  • เพิ่ม routers, filters และการแจ้งเตือนหลังจากการเขียนข้อมูลกลับพื้นฐานมีความเสถียรแล้วเท่านั้น
  • ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
  • เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
  • จัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครบ้างที่ได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจริงในโปรดักชัน
  • ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน
  • Scenario history มีประโยชน์สำหรับ AP เพราะใบแจ้งหนี้ทดสอบแต่ละใบจะเก็บ bundle, route, operation count และรายละเอียด response ไว้ในรันแบบภาพเดียว
  • หลังจากได้หลักฐานแล้ว Make สามารถเพิ่ม aggregator สำหรับชุดใบแจ้งหนี้ data store สำหรับตรวจสอบใบแจ้งหนี้ซ้ำ และโมดูล Slack หรืออีเมลสำหรับเจ้าของงานข้อยกเว้นของ AP ได้

เอกสารอ้างอิงสำหรับการนำไปใช้

เก็บรายละเอียดการตั้งค่าไว้ให้ทีมของคุณ

เวิร์กโฟลว์

จากข้อยกเว้นของใบแจ้งหนี้ใน Make สู่เรคคอร์ดใน Jodoo

Make จัดการสถานการณ์แบบภาพ ส่วน Jodoo เก็บเรคคอร์ดที่ทีมสามารถกรอง มอบหมาย และตรวจสอบได้

  1. Custom webhook รับหรือเริ่มการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ด้วยข้อมูลจำลองก่อน

  2. Make ใช้คำสั่งตรวจสอบที่เจาะจงและส่งกลับประเภทข้อยกเว้น เหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ผู้ตรวจสอบที่ได้รับมอบหมาย เจ้าของงบประมาณ แนวทางแก้ไขที่แนะนำ และลำดับความสำคัญ

  3. HTTP module ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และรับ data ID กลับมา

  4. สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ Make สามารถแยกเส้นทางกรณี PO ไม่ตรงกัน ไม่มีการยืนยันการรับสินค้า และกรณีที่ต้องอนุมัติโดยเจ้าของงบประมาณ ออกเป็นเส้นทางแยกหลังจากการเขียนข้อมูลกลับพื้นฐานได้

  5. ใน body ของ HTTP module ควรเก็บเหตุผลที่พักชำระ ความพร้อมในการชำระเงิน ประเภทข้อยกเว้น และผู้ตรวจสอบที่ได้รับมอบหมายไว้ในฟิลด์ที่แมปไว้อย่างชัดเจน

  6. Scenario history มีประโยชน์สำหรับ AP เพราะใบแจ้งหนี้ทดสอบแต่ละใบจะเก็บ bundle, route, operation count และรายละเอียด response ไว้ในรันแบบภาพเดียว

  7. หลังจากได้หลักฐานแล้ว Make สามารถเพิ่ม aggregator สำหรับชุดใบแจ้งหนี้ data store สำหรับตรวจสอบใบแจ้งหนี้ซ้ำ และโมดูล Slack หรืออีเมลสำหรับเจ้าของงานข้อยกเว้นของ AP ได้

  8. เริ่มด้วย Custom webhook วาง sample request และให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจเข้าไปใน body ของ HTTP module

  9. ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน

  10. Jodoo สร้างเรคคอร์ด Invoice Approval Workflow และจัดเก็บ ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น, เหตุผลของข้อยกเว้น

  11. ทีมตรวจสอบคิว มอบหมายความรับผิดชอบ และดำเนินการขั้นถัดไปให้เสร็จ: พักการชำระเงิน ขอการยืนยันการรับสินค้า และขอให้เจ้าของงบประมาณอนุมัติส่วนต่าง

  12. ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง

  13. เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง

เรคคอร์ด Jodoo

สิ่งที่ Jodoo จัดเก็บ

Jodoo เก็บฟิลด์ข้อยกเว้นของใบแจ้งหนี้แบบถาวรหลังเวิร์กโฟลว์ทำงาน: ชื่อผู้ขาย, หมายเลขใบแจ้งหนี้, วันที่ใบแจ้งหนี้, ยอดใบแจ้งหนี้, หมายเลข PO, วันครบกำหนด, ธงข้อยกเว้น, เหตุผลของข้อยกเว้น

ชื่อผู้ขายหมายเลขใบแจ้งหนี้วันที่ใบแจ้งหนี้ยอดใบแจ้งหนี้หมายเลข POวันครบกำหนดธงข้อยกเว้นเหตุผลของข้อยกเว้นสถานะการลงบัญชีความพร้อมในการชำระเงินสถานะการอนุมัติผู้ตรวจสอบที่ได้รับมอบหมายเจ้าของงบประมาณแนวทางแก้ไขที่แนะนำผลลัพธ์เวิร์กโฟลว์ต้นฉบับ

การทดสอบจริง

เวิร์กโฟลว์ Make เขียนข้อมูลข้อยกเว้นของใบแจ้งหนี้ลงใน Jodoo

ภาพหน้าจอใช้ข้อมูลจำลอง และแสดงการตั้งค่า Make การรันที่สำเร็จ และแถวข้อมูลใน Jodoo ที่เวิร์กโฟลว์สร้างขึ้น

การตั้งค่า Make สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ร่วมกับ Jodoo

การตั้งค่าสถานการณ์ใน Make

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

การรันตรวจสอบข้อยกเว้นของใบแจ้งหนี้ใน Make สำเร็จพร้อมเขียนข้อมูลกลับไปยัง Jodoo

การรัน Make สำเร็จ

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

เรคคอร์ดการตรวจสอบข้อยกเว้นของใบแจ้งหนี้ใน Jodoo ที่สร้างจากผลลัพธ์ของ Make

การเขียนข้อมูลกลับไปยัง Jodoo

การตรวจสอบข้อยกเว้นของใบแจ้งหนี้ถูกเขียนลงใน Jodoo โดยมองเห็นฟิลด์ ชื่อผู้ขาย หมายเลขใบแจ้งหนี้ วันที่ใบแจ้งหนี้ ยอดใบแจ้งหนี้ หมายเลข PO และวันครบกำหนด

FAQ

คำถามที่พบบ่อย

คำตอบเกี่ยวกับการใช้แพลตฟอร์มเอเจนต์ร่วมกับเรคคอร์ด เวิร์กโฟลว์ และเทมเพลตแอปของ Jodoo

การตรวจสอบข้อยกเว้นของใบแจ้งหนี้ด้วย Make นี้ทดสอบครบทั้งกระบวนการแล้วหรือยัง?

ใช่ หลักฐานนี้ใช้ข้อมูลจำลอง มีการรันจริงใน Make และมีภาพหน้าจอการเขียนข้อมูลกลับไปยัง Jodoo ที่ยืนยันแล้วพร้อมบันทึกหลักฐาน

ทำไมจึงควรใช้ Make สำหรับการตรวจสอบข้อยกเว้นของใบแจ้งหนี้?

ใช้ Make เมื่อทีมปฏิบัติการต้องการ scenario canvas ที่มองเห็นได้ การทดสอบแบบ Run once และประวัติโมดูล จากนั้น Jodoo จะเก็บเรคคอร์ดแบบถาวรสำหรับการตรวจสอบและติดตามงาน

การติดตั้งใช้งาน Make นี้แตกต่างจากตัวอย่างแพลตฟอร์มอื่นอย่างไร?

หลักฐานสาธารณะใช้โหมด 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 จัดเก็บอะไรหลังจากเวิร์กโฟลว์ทำงานเสร็จ?

Jodoo จัดเก็บ ชื่อผู้ขาย หมายเลขใบแจ้งหนี้ วันที่ใบแจ้งหนี้ ยอดใบแจ้งหนี้ หมายเลข PO วันครบกำหนด ธงข้อยกเว้น เหตุผลของข้อยกเว้น สถานะการลงบัญชี ความพร้อมในการชำระเงิน รวมถึงผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทการตรวจสอบย้อนหลัง

ภายหลังสามารถเชื่อมต่อกับข้อมูลต้นทางจริงในโปรดักชันได้หรือไม่?

ได้ เริ่มจากการรันข้อมูลจำลองที่ยืนยันแล้ว จากนั้นจึงเชื่อมต่อฟอร์ม พอร์ทัล กล่องข้อความ APIs หรือระบบภายใน เมื่อสคีมาการตรวจสอบข้อยกเว้นของใบแจ้งหนี้มีความเสถียรแล้ว ใช้ router หลังจากหลักฐานพื้นฐานเมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลไม่ครบ ต้องใช้คิว Jodoo ที่แตกต่างกัน

อะไรบ้างที่ทีมควรเป็นผู้ตรวจสอบต่อไป?

เวิร์กโฟลว์สามารถเตรียมฟิลด์การตัดสินใจได้ แต่เจ้าของงานควรตรวจสอบความเสี่ยงทางธุรกิจ การอนุมัติด้านการชำระเงินหรือกฎหมาย และการตัดสินใจขั้นสุดท้ายในการปฏิบัติงานต่อไป พร้อมจัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครบ้างที่ได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจริงในโปรดักชัน

ขั้นตอนถัดไป

เปลี่ยนข้อยกเว้นของใบแจ้งหนี้ให้เป็นงานติดตามที่ตรวจสอบได้

เริ่มจากการรัน Make ที่ยืนยันผลแล้วหนึ่งครั้ง จากนั้นนำรูปแบบการเขียนข้อมูลกลับแบบเดียวกันไปใช้กับคิวการตรวจสอบที่เกี่ยวข้องและการส่งต่องานในการปฏิบัติงาน ตรวจสอบการใช้ operation ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง