โครงร่างแอปคำขอจัดซื้อสำหรับการอนุมัติและใบสั่งซื้อ

สิ่งที่แอปคำขอจัดซื้อภายในควรแก้ไข

เธรดอีเมลและสเปรดชีตล้มเหลวด้วยวิธีที่คาดเดาได้เหมือนกัน คำขอถูกฝังอยู่ ไฟล์แตกออกเป็นรุ่น "final_v7" การอนุมัติเกิดขึ้นในแชทข้างเคียงโดยไม่มีบันทึก เมื่อมีคนถามว่า "เราผ่านให้ซื้อชิ้นนี้ได้หรือยัง?" คำตอบขึ้นอยู่กับว่าใครออนไลน์และพวกเขาเชื่อชีตไหน

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

อย่างน้อยที่สุด คำขอแต่ละรายการควรตอบคำถามเหล่านี้โดยไม่ต้องขุดค้น:

• ใครเป็นเจ้าของขั้นตอนถัดไป?
• มีอะไรค้างอยู่ (การอนุมัติ, การตรวจสอบงบ, ใบเสนอราคา, การสร้าง PO)?
• อะไรที่ได้รับการอนุมัติ (ยอด, ผู้ขาย, ขอบเขต) และมีการเปลี่ยนแปลงหรือไม่?
• ต้องการเมื่อไหร่ และทำไม?
• มีเส้นทางตรวจสอบอย่างไรเพื่อให้การเงินเชื่อถือได้?

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

เริ่มจากเวอร์ชันแรกให้เรียบง่าย เริ่มด้วยทีมเดียว เส้นทางอนุมัติเดียว และคำนิยามที่ชัดเจนของ "เสร็จสิ้น" ตัวอย่างเช่น คำขอ IT ที่ต่ำกว่า $1,000 อาจต้องการเพียงการอนุมัติของผู้จัดการ ในขณะที่การซื้อที่มากกว่านั้นจะส่งต่อไปยังการเงิน

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

ผู้ใช้ บทบาท และกฎการเข้าถึง

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

เริ่มด้วยการตั้งชื่อบทบาทให้ชัดเจน ตำแหน่งอาจต่างกันตามบริษัท แต่แอปส่วนใหญ่ต้องการความรับผิดชอบที่คงที่: ผู้ขอ (สร้างคำขอและตอบคำถาม), ผู้จัดการ (ยืนยันวัตถุประสงค์และเวลา), ทีมจัดซื้อ (ตรวจสอบผู้ขายและสร้าง PO), การเงิน (ยืนยันงบและนโยบาย), และผู้อนุมัติหนึ่งคนหรือมากกว่า (มีอำนาจลงนาม) บางเวิร์กโฟลว์ยังรวมถึงผู้ติดต่อผู้ขายที่เข้าถึงจำกัดสำหรับรายละเอียดที่ต้องแชร์กับภายนอก

จากนั้นกำหนดว่าทุกบทบาททำอะไรได้ในแต่ละขั้นตอน กฎหนึ่งข้อป้องกันข้อพิพาทได้มาก: เมื่อคำขอถูกส่ง ผู้ขอสามารถแก้ไขได้เฉพาะการชี้แจง (โน้ต, ไฟล์แนบ, รายละเอียดการจัดส่ง) เท่านั้น ราคา ผู้ขาย จำนวน สกุลเงิน และศูนย์ต้นทุนควรถูกตั้งเป็นฟิลด์ที่ต้องมีการเปลี่ยนแปลงอย่างเป็นทางการและการอนุมัติใหม่

กฎการมองเห็นควรชัดเจนเช่นกัน ผู้ขอควรเห็นคำขอของตนเองและสถานะ ผู้จัดการควรเห็นคำขอจากผู้ใต้บังคับบัญชาตน Procurement และ Finance มักต้องการการมองเห็นข้ามแผนก ผู้ติดต่อผู้ขายไม่ควรเห็นบันทึกภายใน ข้อมูลงบประมาณ หรือผู้ขายอื่น

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

คำขอข้ามแผนกเป็นเรื่องปกติ (เช่น IT ซื้อซอฟต์แวร์ให้การตลาด) แยก "ทีมผู้ขอ" ออกจาก "เจ้าของศูนย์ต้นทุน" เส้นทางอนุมัติส่งไปยังเจ้าของศูนย์ต้นทุน และแสดงทั้งสองในเรคอร์ดเพื่อให้เห็นชัดว่าใครขอและใครจ่าย

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

โมเดลข้อมูล: เอนทิตีและฟิลด์หลัก

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

เอนทิตีหลักที่ควรมี

ทีมส่วนใหญ่ครอบคลุมกรณีส่วนใหญ่ด้วยชุดเอนทิตีขนาดเล็ก:

• Requests: เรคอร์ดหนึ่งรายการต่อคำขอจัดซื้อ (ส่วนหัว)
• RequestItems: รายการบรรทัด จำนวน และราคาต่อหน่วยที่ประมาณการ
• Vendors: ข้อมูลผู้ส่งมอบที่ใช้ซ้ำได้ทั่วคำขอและ PO
• Budgets: จำนวนเงินที่ใช้ได้ตามศูนย์ต้นทุน โปรเจกต์ แผนก หรือช่วงเวลา
• PurchaseOrders: ใบสั่งซื้อทางการสร้างจากคำขอที่อนุมัติแล้ว
• Approvals: แต่ละขั้นตอนการอนุมัติ การตัดสินใจ และความคิดเห็น

ฟิลด์ที่จะคุ้มค่าในอนาคต

สำหรับ Requests ให้รวมฟิลด์ที่ช่วยการส่งต่อและลดการคุยกลับ: ผู้ขอ แผนก ศูนย์ต้นทุน วันที่ต้องการ เหตุผลทางธุรกิจ และไฟล์แนบ (ใบเสนอราคา สเปก สกรีนช็อต) การอ้างอิงผู้ขายที่ต้องการแบบง่าย ๆ ก็ช่วยได้ แม้ว่าการเลือกผู้ขายจะสรุปทีหลัง

สถานะทำงานได้ดีที่สุดเมื่อชัดเจนและมีตราประทับเวลา เก็บฟิลด์สถานะเดียวบน Requests (Draft, Submitted, Approved, Rejected, Ordered, Closed) และเก็บวันที่สำคัญเช่น submitted_at, approved_at, rejected_at, ordered_at, closed_at การออกแบบนี้ทำให้การรายงาน (เวลาในรอบงาน, อายุงาน, จุดคอขวด) ทำได้โดยไม่ต้องเดาจากล็อก

สำหรับ PurchaseOrders แยกส่วนหัวของ PO (หมายเลข ผู้ขาย ที่อยู่จัดส่ง ที่อยู่เรียกเก็บ เงื่อนไขการชำระเงิน) ออกจากไลน์ไอเท็มของ PO และเชื่อมโยงกลับไปยังคำขอและไอเท็มต้นทาง การเชื่อมโยงนี้สำคัญเมื่อราคามีการเปลี่ยนแปลง

การออกแบบเส้นทางตรวจสอบ

การอนุมัติคือบันทึกตรวจสอบของคุณ แต่คุณมักต้องการมากกว่าแค่ "อนุมัติ/ปฏิเสธ" เก็บว่าใครทำ เมื่อไร ตัดสินอย่างไร และเพราะเหตุใด

แนวทางแบบน้ำหนักเบาคือมีกลุ่ม Activity/Audit ที่บันทึก actor_user_id, entity_type, entity_id, action, old_value, new_value, และ created_at ใน AppMaster การออกแบบนี้แมปได้ตรงใน Data Designer และสามารถเติมอัตโนมัติจากกระบวนการธุรกิจเพื่อให้ทุกการเปลี่ยนแปลงติดตามได้

ข้อมูลผู้ขายและการติดตามการสื่อสาร

แอปคำขอจัดซื้อทำงานได้เมื่อทุกคนใช้ข้อมูลผู้ขายชุดเดียว ปฏิบัติต่อตารางผู้ขายเป็นแหล่งความจริงเดียว อย่าให้คนพิมพ์ซ้ำในแต่ละคำขอ เมื่อรายละเอียดผู้ขายอยู่ที่เดียว การอนุมัติจะเร็วขึ้นและการเงินจะเจอความประหลาดใจน้อยลง

เริ่มด้วยเรคอร์ดผู้ขายที่เก็บข้อมูลพื้นฐานที่ใช้ซ้ำ: ชื่อทางกฎหมาย ชื่อแสดง หมายเลขประจำตัวผู้เสียภาษี (ถ้าต้องการ) สกุลเงินเริ่มต้น ที่อยู่เรียกเก็บ เงื่อนไขการชำระเงิน อีเมลบัญชีเจ้าหนี้หลัก และอนุญาตให้มีหลายผู้ติดต่อเพื่อใช้คนที่เหมาะสมสำหรับใบเสนอราคากับอินวอยซ์

เพิ่มสถานะผู้ขายเพื่อให้แอปบล็อกการซื้อที่เสี่ยงได้อย่างสม่ำเสมอ: Active (เลือกได้), Pending review (อนุญาตแต่ต้องการการตรวจสอบเพิ่ม), Blocked (ไม่สามารถใช้ได้โดยไม่มีการทบทวน)

การติดตามการสื่อสารป้องกันปัญหา "ใครอีเมลหาผู้ขายล่าสุด?" สร้างเอนทิตี Communication (หรือ VendorInteraction) เชื่อมกับ Vendor และเมื่อเป็นไปได้เชื่อมกับ Request, Quote, หรือ Purchase Order แต่ละเรคอร์ดควรเก็บช่องทาง (อีเมล, โทร, ประชุม), ทิศทาง (ขาออก/ขาเข้า), ตราเวลา, เจ้าของ, และสรุปสั้น ๆ หากเก็บใบเสนอราคา ให้เก็บเป็นเรคอร์ดเชิงโครงสร้าง (จำนวน, สกุลเงิน, วันหมดอายุ) และแนบไฟล์เมื่อจำเป็น

กฎไม่กี่ข้อช่วยให้ข้อมูลผู้ขายสะอาดโดยไม่ชะลอผู้ใช้:

• เลือกผู้ขายจากรายการ ไม่ใช่ข้อความอิสระ
• ล็อกเงื่อนไขการชำระเงินหลังจากสร้าง PO เว้นแต่ต้องการการอนุมัติ
• ส่งต่อผู้ขายในสถานะ Pending review ไปยัง procurement อัตโนมัติ
• สำหรับการซื้อมูลค่าสูง ต้องมีการบันทึกการติดต่ออย่างน้อยหนึ่งครั้งและไทม์ไลน์ของใบเสนอราคาที่มองเห็นได้

หากสร้างใน AppMaster คุณสามารถจำลอง Vendor, VendorContact, และ VendorCommunication ใน Data Designer และแสดงไทม์ไลน์บนหน้าคำขอและ PO เพื่อให้ประวัติเต็มที่อยู่เพียงคลิกเดียว

การตรวจสอบงบ: วิธียืนยันการใช้เงินก่อนการอนุมัติ

การตรวจสอบงบตอบคำถามง่าย ๆ: เรามีเงินที่อนุมัติพอสำหรับคำขอนี้ตอนนี้หรือไม่? ตัดสินใจตั้งแต่ต้นว่าบริษัทของคุณมองงบเป็นจุดหยุดแข็ง (ไม่สามารถไปต่อ) หรือเป็นคำเตือน (สามารถไปต่อแต่ต้องการการอนุมัติเพิ่ม) การตัดสินใจนี้เปลี่ยนประสบการณ์สำหรับผู้ขอและผู้อนุมัติทั้งหมด

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

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

เช็คลิสต์การคำนวณง่าย ๆ ที่ทีมส่วนใหญ่ใช้รวมยอดไลน์ไอเท็ม (qty x unit price), ส่วนลด, ภาษี, ค่าส่งและค่าจัดการ, และการแปลงสกุลเงิน (เก็บอัตราและวันที่อัตรา) แล้วเปรียบเทียบยอดคาดการณ์กับงบที่มี (งบลบกับยอดที่ถูกผูกไว้แล้ว) หากคุณติดตามการผูกงบ ให้รวมคำขอที่รอดำเนินการและ PO ที่เปิดอยู่ ไม่ใช่แค่อินวอยซ์ที่จ่ายแล้ว

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

ตัวอย่าง: ทีมขอชุดแลปท็อปใหม่ แอปคำนวณยอดรวมบวกภาษีและค่าจัดส่ง แปลงเป็นสกุลเงินของแผนก และแจ้งว่าเหลือ $900 แต่คำขอเป็น $1,150 หากมองเป็นคำเตือน ก็ยังส่งไปยังผู้จัดการได้ แต่การอนุมัติจากการเงินจะเป็นข้อบังคับ

ใน AppMaster คุณสามารถจำลองแหล่งงบใน Data Designer และรันการตรวจสอบเป็นขั้นตอนของ Business Process ก่อนการตัดสินใจอนุมัติครั้งแรก

เวิร์กโฟลว์การอนุมัติและกฎการส่งต่อ

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

เริ่มจากกำหนดว่าการอนุมัติแต่ละประเภทปกป้องอะไร โดยทั่วไปคือการอนุมัติของผู้จัดการ (ความจำเป็นและลำดับความสำคัญ), การอนุมัติทางการเงิน (งบและบัญชี), และการอนุมัติของการจัดซื้อ (ผู้ขายและวิธีการซื้อ) เพิ่มความปลอดภัยและกฎหมายเฉพาะเมื่อหมวดหรือผู้ขายบางประเภทต้องการ

กฎการส่งต่อควรเป็นที่คาดเดา ผู้คนควรเดาได้ว่าจะเกิดอะไรขึ้นถัดไปก่อนกด Submit ปัจจัยการส่งต่อทั่วไปได้แก่ เกณฑ์จำนวน การส่งต่อตามหมวด (ซอฟต์แวร์ไปฝ่ายความปลอดภัย, สัญญาไปกฎหมาย), ระดับความเสี่ยงของผู้ขาย, กฎแผนกหรือศูนย์ต้นทุน, และประเภทการซื้อ (CapEx vs OpEx, สมัครสมาชิกรายเดือน vs ครั้งเดียว)

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

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

ตัวอย่าง: SaaS มูลค่า $12,000 ส่งต่อไปยังผู้จัดการและการเงินก่อน หลังจากทั้งสองอนุมัติ ความปลอดภัยและการจัดซื้อทำงานขนาน หากความปลอดภัยพบข้อมูลการประมวลผลข้อมูลที่ขาดไป มันจะส่งกลับผู้ขอ แล้วเมื่อผู้ขอส่งกลับก็จะกลับไปยังขั้นตอนเดิมพร้อมบันทึกตรวจสอบ

หากสร้างใน AppMaster ให้จำลองสถานะเวิร์กโฟลว์และการเปลี่ยนสถานะใน Business Process เพื่อให้การส่งต่อมองเห็นได้และปรับได้ง่ายตามนโยบาย

ขั้นตอนทีละขั้น: จากคำขอถึงใบสั่งซื้อ

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

ลำดับปฏิบัติที่ใช้ได้กับหลายทีม:

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

ตัวอย่าง: ทีมสนับสนุนขอหูฟัง 10 ชุด พวกเขาแนบใบเสนอราคา เลือกหมวดอุปกรณ์ IT และส่ง แอปเช็คลบงบ IT ส่งต่อไปยังหัวหน้าทีม (ต่ำกว่า $1,000) แล้วการเงิน (มากกว่า $500) หลังจากอนุมัติแล้ว PO ถูกสร้างและส่ง ผู้ซื้อบันทึกการยืนยันและวันที่จัดส่ง

ในเครื่องมือ no-code เช่น AppMaster นี่มักกลายเป็นไม่กี่หน้าจอ (Draft, Review, PO) บวก Business Process ที่ล็อกฟิลด์ รันตรรกะงบ และสร้างเรคอร์ด PO อัตโนมัติ

ใบสั่งซื้อ: การตั้งหมายเลข ไลน์ไอเท็ม และการควบคุมการเปลี่ยนแปลง

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

การตั้งหมายเลข PO: เมื่อควรสร้าง

สร้างหมายเลข PO เมื่อ PO ถูกออกอย่างเป็นทางการให้ผู้ขาย ไม่ใช่ตอนเริ่มร่าง ฉบับร่างถูกลบ เริ่มใหม่ และรวมกัน นั่นคือสาเหตุที่เกิดช่องว่างและซ้ำซ้อน

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

โครงสร้าง PO: ส่วนหัว ไลน์ และยอดรวม

แยก PO เป็นส่วนหัวและไลน์ไอเท็ม ส่วนหัวเก็บบริบท; ไลน์เก็บสิ่งที่คุณจะซื้อ

เก็บส่วนหัวให้เน้น: ผู้ขายและผู้ติดต่อ, ที่อยู่จัดส่งและที่อยู่ออกใบเรียกเก็บ, สกุลเงิน, เงื่อนไขการชำระเงิน, วันที่คาดว่าจะส่ง, สถานะ (Draft, Issued, Acknowledged, Closed), และการอ้างอิงใบเสนอราคา

ไลน์ไอเท็มควรเข้มงวดพอสำหรับการจับคู่อินวอยซ์ในภายหลัง: คำอธิบาย, จำนวน, หน่วย, ราคาต่อหน่วย, ภาษี, ส่วนลด, และรหัสศูนย์ต้นทุนหรือรหัสงบ ยอดรวมควรถูกคำนวณ ไม่ใช่พิมพ์ด้วยมือ

การควบคุมการเปลี่ยนแปลง: แก้ไข vs ยกเลิกและออกใหม่

ตัดสินใจตั้งแต่ต้นว่าเมื่อใดอนุญาตให้แก้ไขได้ การเปลี่ยนแปลงเล็กน้อยเช่นวันที่จัดส่งหรือบันทึกสามารถเป็นเวอร์ชันแก้ไข (เช่น PO-1042 v2) พร้อมลิงก์ "ยกเลิก v1" ชัดเจน การเปลี่ยนแปลงใหญ่เช่นผู้ขาย สกุลเงิน หรือการเปลี่ยนแปลงจำนวนรวมอย่างมีนัยสำคัญควรยกเลิกและออกใหม่เพื่อไม่ให้ใครส่งของตามเอกสารผิด

ตัวอย่าง: คำขออนุมัติสำหรับ 10 แล็ปท็อป แต่ใบเสนอราคาจากผู้ขายเปลี่ยนจากส่งภายใน 2 สัปดาห์เป็น 8 สัปดาห์ ให้สร้างการแก้ไขพร้อมวันที่จัดส่งอัปเดตและเก็บเอกสารใบเสนอราคาต้นฉบับไว้เพื่อให้ PO ตรงกับที่ตกลงกันเสมอ

ถ้าสร้างใน AppMaster ให้จำลอง PO header, PO line items, และเวอร์ชัน PO เป็นเอนทิตีแยกต่างหากเพื่อให้การแก้ไขสะอาดและตรวจสอบได้

การแจ้งเตือนและเวิร์กโฟลว์การสื่อสารกับผู้ขาย

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

เริ่มด้วยชุดการอัปเดตภายในเล็ก ๆ เพื่อไม่ให้คนละเลย: อนุมัติ/ปฏิเสธ, การตรวจสอบงบล้มเหลวหรือขอชี้แจง, สร้าง PO และพร้อมส่ง, การอนุมัติล่าช้าหรือวันส่งมอบล่าช้า, PO ถูกเปลี่ยนหรือยกเลิก

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

การสื่อสารกับผู้ขายก็ควรมีโครงสร้าง ผู้ขายส่วนใหญ่ต้องการ PO, การเปลี่ยนแปลง PO, การยกเลิก และคำถามเกี่ยวกับการจัดส่ง เก็บทุกข้อความขาออกและขาเข้าบนเธรดผู้ขายสำหรับ PO หรือคำขอนั้น ๆ ติดตามผลลัพธ์ด้วยฟิลด์เรียบง่ายเช่น status (draft, sent, delivered, failed), vendor_response (none, replied, bounced), follow_up_needed (yes/no), และ follow-up date

ตัวอย่าง: คำขอแล็ปท็อปได้รับการอนุมัติ PO ถูกส่ง และผู้ขายตอบกลับว่าแบบนี้ขาดสต็อก แอปจะบันทึกการตอบกลับ ตั้ง follow_up_needed เป็น yes และแจ้งผู้ขอให้เลือกตัวเลือกอื่น ใน AppMaster คุณสามารถเชื่อมการเปลี่ยนสถานะกับขั้นตอนอีเมล/SMS/Telegram และบันทึกผลข้อความควบคู่กับ PO ได้

ความผิดพลาดทั่วไปและกับดักที่ควรหลีกเลี่ยง

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

หนึ่งความล้มเหลวทั่วไปคือแปลงคำขอให้เป็นเขาวงกตของสถานะ หากคนไม่รู้ว่า "Pending validation" ต่างจาก "Under review" อย่างไร พวกเขาจะหยุดอัปเดตและข้อมูลก็กลายเป็นเสียงรบกวน จงทำให้สถานะผูกกับการกระทำและเจ้าของที่ชัดเจน ทุกสถานะควอตอบคำถามเดียว: "ต่อไปเกิดอะไรขึ้น และใครทำ?"

กับดักอีกอย่างคือการมอบหมายการอนุมัติโดยไม่มีเจ้าของหรือกำหนดเวลา คำขอติดเมื่อผู้อนุมัติลาออกหรือบทบาทไม่ชัดเจน ("การเงิน" ไม่ใช่คน) เพิ่มการสำรองและคาดหวังเวลาง่าย ๆ แม้ไม่เป็นทางการ

ความผิดพลาดที่ทำให้ต้องทำซ้ำมากที่สุดคือ:

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

การแก้ไขหลังการอนุมัติสมควรได้รับความสนใจพิเศษเพราะการเปลี่ยนแปลงเล็ก ๆ ที่ดูปลอดภัยมักเปลี่ยนความเสี่ยง หากใครได้รับอนุมัติ 10 แล็ปท็อปที่ราคา $900 แล้วต่อมามีการเปลี่ยนเป็นรุ่นที่แพงขึ้นหรือเพิ่มจำนวน คุณอาจมีการอนุมัติที่ไม่สะท้อนสิ่งที่ซื้อจริง

และอย่าเห็นการตรวจสอบงบเป็นฟิลด์ใช่/ไม่ใช่ ฝ่ายการเงินมักสนใจวิธีการรายงานการใช้จ่าย: แผนก โปรเจกต์ บัญชี GL และหน้าต่างเวลา หากแอปรันการตรวจสอบงบเป็นรายเดือนแต่การเงินรายงานเป็นรายไตรมาส ยอด "งบที่มี" จะผิดเสมอ

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

เช็คลิสต์ด่วน ตัวอย่างสถานการณ์ และขั้นตอนต่อไป

ก่อนเปิดใช้งาน ให้เขียนสิ่งพื้นฐานลง Most "approval chaos" เกิดเพราะมีกฎเล็ก ๆ หรือละเอียดที่ต้องการแต่ขาดไป

เช็คลิสต์การเปิดตัวง่าย ๆ:

• บทบาทและสิทธิ์ (ผู้ขอ, ผู้อนุมัติ, การเงิน, การจัดซื้อ, ผู้ดูแล)
• กฎการอนุมัติ (จำนวน, แผนก, หมวด, สถานที่)
• สถานะและความเป็นเจ้าของ (Draft, Submitted, Needs info, Approved, PO created, Closed)
• ฟิลด์ที่บังคับ (ผู้ขาย, ศูนย์ต้นทุน, วันที่ส่ง, เหตุผลทางธุรกิจ)
• ไฟล์แนบที่จำเป็น (ใบเสนอราคา, สัญญา, การทบทวนความปลอดภัย, แผ่นสเปก)

เมื่อมีกฎเหล่านี้แล้ว ให้เพิ่มการตรวจสอบด่วนที่รันก่อนคำขอจะไปต่อ: การเลือกผู้ขาย (หรือลำดับการสร้างผู้ขายใหม่ที่ชัดเจน), ความครอบคลุมงบสำหรับช่วงเวลาที่ถูกต้อง, หลักฐานราคาที่ครบถ้วน, รายละเอียดการจัดส่ง/เรียกเก็บที่สมบูรณ์, และเหตุผลทางธุรกิจที่แท้จริง

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

ขั้นตอนต่อไป: จำลองโมเดลข้อมูลและกฎเวิร์กโฟลว์ แล้วทดสอบกับทีมทดลองขนาดเล็กและหนึ่งหรือสองหมวดการซื้อ ใน AppMaster คุณสามารถสร้างตารางใน Data Designer และแม็ปตรรกะการส่งต่อใน Business Process Editor รันไฟล์พายโลตสั้น ๆ ทบทวนจุดที่คำขอติดให้กระชับฟิลด์ที่บังคับ แล้วค่อยขยาย หากต้องการดูว่ากระบวนการนี้แปลงเป็นการสร้างแอปจริงอย่างไร AppMaster (appmaster.io) ถูกออกแบบมาเพื่อสร้างเครื่องมือภายในเต็มรูปแบบพร้อมตรรกะการอนุมัติ API และทั้งเว็บและมือถือจากโมเดลเดียวกัน