ข้ามไปยังเนื้อหาหลัก

การอนุมัติ

ศูนย์อนุมัติคือที่ที่ผู้จัดการดำเนินการคำขอที่ต้องมีคนที่สองตรวจสอบ — การแก้ไขการปิดรอบ ความคลาดเคลื่อนเงินสด และการแก้ไขการตรวจนับ

หน้าจอแอปพลิเคชันปัจจุบัน

เข้าถึงศูนย์อนุมัติ​

Admin → รายงานและการเงิน → ศูนย์อนุมัติ เข้าจากแถบข้าง หรือจากลิงก์ตรวจสอบคำขออนุมัติของสาขาบนหน้าข้อมูลเชิงลึกสำหรับเจ้าของ — ไม่มีป้ายรอดำเนินการบนแดชบอร์ด

หน้ามี 4 แท็บ:

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

แต่ละแท็บแสดงรอดำเนินการตามค่าเริ่มต้น; สลับไปประวัติเพื่อดูการตัดสินใจเก่า

คำขอแก้ไขการปิดรอบ​

เมื่อบันทึกการปิดรอบที่ปิดผนึกแล้วมีข้อผิดพลาด (ยอดเทอร์มินัลผิด รายการชำระที่หายไป) พนักงาน POS ใช้ Request reopen ในหน้ารายละเอียดเพื่อขอแก้ไขแบบมีเวอร์ชัน ชื่อปุ่มนี้เริ่มขั้นตอนแก้ไขที่ต้องอนุมัติ; ไม่ได้ทำให้รอบธุรกิจที่ปิดแล้วกลับมาใช้งาน

อนุมัติ / ปฏิเสธ​

  1. เปิดคำขอที่รอ — คุณจะเห็นใครขอ เมื่อไหร่ และเหตุผล
  2. อนุมัติ (พร้อมหมายเหตุ) → ผู้ขอแก้ไขส่วนที่อนุญาตและสร้างเวอร์ชันถัดไปสำหรับรอบธุรกิจและวันที่ธุรกิจเดิม
  3. ปฏิเสธ (พร้อมหมายเหตุ) → คำขอปิด; เวอร์ชันที่ปิดผนึกอยู่ยังคงใช้
คำเตือน

การแยกหน้าที่ การเปิดสรุปยอดใหม่และความคลาดเคลื่อนเงินสดถูกขอจาก POS โดยพนักงาน และอนุมัติใน Admin โดยบัญชี admin — เป็นระบบตัวตนสองระบบแยกกัน ผู้ขอจึงไม่มีทางเป็นผู้อนุมัติได้ ส่วนการเปิดตรวจนับใหม่และการแก้ไขข้อมูลการเงินยังปฏิเสธการอนุมัติตัวเองอย่างชัดเจนที่ระดับ API เพิ่มเติมด้วย

คำขอแก้ไขทางการเงิน (ช่วงเวลาที่ปิดแล้ว)​

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

สองสิ่งที่ต้องตรวจบนการ์ดคำขอก่อนอนุมัติ:

  • ตัวอย่าง Adjustment Note หากการชำระเงินที่แก้ไขอยู่ใน Visit ที่ออก Tax Invoice แล้ว การ์ดจะแสดง Adjustment Note (ลดหรือเพิ่ม ราคาก่อน → หลัง การเปลี่ยนแปลง GST วันที่ note) ที่จะออกณ ขณะที่คุณอนุมัติ สิ่งที่เห็นคือสิ่งที่ออก — ถูกตรึงตอนสร้างคำขอ และระบบจะปฏิเสธการอนุมัติหากใบแจ้งหนี้เปลี่ยนไปในระหว่างนั้น ใบแจ้งหนี้เดิมไม่ถูกแก้ไขและไม่ถูกแทนที่อัตโนมัติ การปฏิเสธไม่ออกเอกสารใด ๆ note นี้อยู่ในรอบ BAS ใดยังไม่ได้รับการตรวจสอบโดยนักบัญชี
  • หมายเลขอ้างอิงเคลม HICAPS การแก้ไขที่แตะการชำระเงิน HICAPS ต้องอ้างหมายเลขเคลม HICAPS การอนุมัติจะเข้าคิวเคสกระทบยอด HICAPS ในข้อยกเว้นทางการเงินด้วย ยอดกองทุนสุขภาพไม่ถูกกระทบยอดอัตโนมัติ — ยังต้องมีคนปิดเคสนั้นด้วยมือ

หาก Visit มี Tax Invoice ที่เปิดอยู่มากกว่าหนึ่งใบ หรือใบแจ้งหนี้เก่าที่ไม่มีข้อเท็จจริง GST จะสร้างคำขอไม่ได้ ให้จัดการใบแจ้งหนี้ก่อน

ความคลาดเคลื่อนเงินสดในลิ้นชัก​

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

อนุมัติความคลาดเคลื่อน​

  1. เปิดความคลาดเคลื่อนที่รอ — คุณจะเห็นยอดคาดหวัง ยอดนับ และส่วนต่าง
  2. เลือกอนุมัติความแตกต่าง (ส่วนต่างถูกเก็บไว้ในบันทึกตามเดิม) หรือส่งไปสอบสวน ทั้งสองต้องมีหมายเหตุอธิบาย (เช่น "การปรับเงินทุนที่ไม่ได้บันทึก" "พนักงานซื้ออาหารจากกล่องแต่ไม่บันทึกค่าใช้จ่าย")
  3. จากการสอบสวนมีทางออกสองทาง: แก้ไขการสอบสวนยอมรับตัวเลขที่นับเป็นการขาด/เกินจริง (จำนวนไม่เปลี่ยน) ส่วนสร้างเวอร์ชันแก้ไขจะถามยอดปิดที่แก้ไขแล้ว และสร้างเวอร์ชันลิ้นชักใหม่พร้อมเวอร์ชัน settlement ฉบับร่าง

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

เปิดตรวจนับใหม่ (ถ้าเปิดคลังสินค้า)​

การตรวจนับที่ยืนยันแล้วล็อกระดับสต็อก ถ้าพบข้อผิดพลาดในการนับ:

  1. ส่งคำขอเปิดตรวจนับใหม่
  2. Admin คนอื่นอนุมัติ → ระบบสร้างเวอร์ชันตรวจนับฉบับร่างใหม่โดยตั้งต้นจากสต็อกปัจจุบัน เวอร์ชันที่นำไปใช้แล้วและการเคลื่อนไหวสต็อกของมันไม่ถูกเขียนทับเลย
  3. เวอร์ชันใหม่ถูกนับ ยืนยัน และนำไปใช้เหมือนการตรวจนับทั่วไป

แนวทางปฏิบัติที่ดี​

  • ล้างการอนุมัติทุกวัน — เปิดศูนย์อนุมัติจากแถบข้างทุกเช้า; ปล่อยสะสมจะสูญเสียบริบทของเหตุการณ์
  • แนบหมายเหตุเสมอ — "อนุมัติแล้ว" โดยไม่มีคำอธิบายมีประโยชน์น้อยกว่า "อนุมัติแล้ว: ขาด $5 เป็นค่าอาหารกลางวันที่ไม่ได้บันทึก"
  • ดูรูปแบบ — ความคลาดเคลื่อนซ้ำ ๆ ที่ร้าน/กะเดียวกันอาจบ่งบอกปัญหาการฝึกหรือสิ่งที่ร้ายแรงกว่า ประวัติการอนุมัติคือหลักฐาน

ใครอนุมัติได้​

บทบาทอนุมัติได้
ผู้จัดการสาขาร้านที่ผูกกับบัญชีของตน — คำขอปิดยอด ลิ้นชักเงินสด และตรวจนับสต็อก; โดยค่าเริ่มต้นขอแก้ไขทางการเงินได้แต่อนุมัติไม่ได้ (tenant admin ให้สิทธิ์อนุมัติได้ในหน้าสิทธิ์ตามบทบาท)
ผู้จัดการภูมิภาคร้านในกลุ่มสาขาของตน; อนุมัติการแก้ไขทางการเงินได้โดยค่าเริ่มต้น (tenant admin เพิกถอนสิทธิ์นี้ได้)
Tenant adminทุกร้านของธุรกิจ
Super adminทุกร้าน

ขอบเขตคือร้านที่บัญชีของคุณเข้าถึงได้ "ผู้จัดการ" ฝั่ง POS เป็นบทบาทการจ้างงานอีกบทบาทหนึ่ง และผู้ใช้ POS เป็นผู้ขอ ไม่ใช่ผู้อนุมัติ

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