FR1 — Mobile Online Check-In สำหรับ driver

นี่คือ requirement ระดับร่ม (umbrella) ของฟีเจอร์หลักข้อแรกของ SCCC: mobile application สำหรับ driver เพื่อทำกิจกรรม check-in แบบ end-to-end สำหรับการรับปูนที่โรงงาน SRB (สระบุรี) โดยเริ่มทำ online, off-site, ก่อนเดินทางมาถึง (RFP p20, FR#1; RFP p16, Use Case #1). ได้รับการ cross-confirm ทั้งใน RFP functional-requirement table, RFP use-case table, To-Be process flow และ Requirement Summary deck — จึงเป็น confirmed.

สิ่งที่ลูกค้าต้องการ

FR#1 (RFP p20): "Enable mobile Online Check-In for drivers — Feature on mobile application designed for drivers to initiate and proceed with end to end check-in activities for receiving cement at SRB plant. This feature follow the business condition and allow for configurability, such as setting the radius and tolerance time. Additionally, it interface the data with existing queue management system (DAS), providing mostly real-time updates." คำว่า "mostly real-time" เป็นถ้อยคำของลูกค้าเอง และมีผลต่อการวาง framing ของ SLA (RFP p20).

Platform: app ต้องรองรับทั้ง Android และ iOS รวมถึง mobile device ทุกรุ่น (RFP p21 row 1). ภาพรวม (RFP p11) อธิบาย Online Check-In ว่า "facilitated through a mobile application majority used by drivers" ซึ่งมีจุดประสงค์ให้ driver เริ่ม check-in แบบ online, ดูสถานะคิวแบบ real-time และรับ notification เมื่อคิวของตนถูกเรียก.

Use Case #1 — "Check-In online prior arriving at SRB plant" (RFP p16-17):

• Actor: Driver.
• Preconditions (RFP p16): ฟีเจอร์เปิดใช้ได้เฉพาะเมื่อ driver อยู่ใกล้/รอบ ๆ โรงงาน SRB (validate ผ่าน geofencing ของ mobile GPS); จำลองขั้นตอน check-in ที่จำเป็นจาก kiosk check-in; interface ข้อมูลกับ DAS เพื่อ validation & status update; และมีขั้นตอน identity verification เช่น facial scanning หลังจาก driver มาถึงโรงงาน โดยเฉพาะสำหรับ DL service (delivery). ดู รัศมี Geofence สำหรับ off-site check-in สำหรับ parameter ของรัศมี.
• Postconditions (RFP p16): หลัง driver ทำ Check-In 1 บน app เสร็จ ข้อมูลจะ trigger ไป DAS เพื่อจองคิว และระบบจะ แนะนำเวลาโดยประมาณที่ควรมาถึง โรงงานเพื่อทำ Check-In 2.
• Normal course (RFP p16): log in เข้า mobile app → เลือกหรือกรอก shipment number → อัปเดตข้อมูลที่เกี่ยวข้อง (ระบบ verify ความถูกต้อง) → ทำ check-in เสร็จและรับคิว → มาถึงโรงงานภายใน tolerance time → ทำ identity verification และ input/scan RFID barcode เพื่อทำ Check-In 2 ให้เสร็จ → ดู loading document.
• Frequency of use (RFP p17): Daily, 700–1000 transactions per day. นี่คือตัวเลข load หลักของฟีเจอร์ check-in.

ลำดับ two-stage แบบ geofenced (RFP p17 Business Logics): ลำดับกิจกรรมเป็น Check-In 1 (Mobile) → Gate-In → Check-In 2 (Mobile) อย่างเคร่งครัด. CI1 ทำแบบ off-site ภายใน geofence (จองคิวที่ DAS, FCFS ตาม timestamp ที่ทำ CI1 เสร็จ); จากนั้น driver ต้องมาถึงและ Gate-In ภายใน tolerance/window time; CI2 ทำเสร็จที่โรงงานหลัง scan RFID และ verify ตัวตน driver. สไลด์ To-Be Online Check-In (SUM p11) และ swimlane (SUM p12) ยืนยัน journey สี่ขั้นตอนเดียวกัน: Check-In (within radius) → Arrived at factory (by window time) → Gate-In process → Parking Exit. ลำดับและ logic การมาถึงนี้มีรายละเอียดใน Flow Online Check-In แบบ To-Be (mobile แบบ geofence, CI1 → Gate-In → CI2) และ การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In.

การแยกรายละเอียด

Record ระดับร่มนี้อยู่เหนือ record รายละเอียดสี่ตัวที่บรรจุข้อกำหนดเต็มจาก compliance matrix:

• Online Check-In — ข้อกำหนด generic / UX (matrix rows 1-19) — rows generic / UX (RFP p21-22).
• Online Check-In — การกรอกและตรวจสอบข้อมูล (shipment / truck / identity) — การกรอกและตรวจสอบข้อมูล shipment / truck / identity (RFP p22-23).
• Online Check-In — การจัดสรรคิว การแสดงผล การแจ้งเตือน และ loading document — การจัดสรรคิว การแสดงผล การแจ้งเตือน และ loading document (RFP p24-25).
• Online Check-In — การยกเลิก การจบรายการ ข้อมูล และ audit — การยกเลิก การจบรายการ ข้อมูล และ audit (RFP p25, RFP p30-31).

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• รัศมี geofence และเวลา tolerance/window/overdue ระบุชัดว่า configurable แต่ค่าตัวเลขเป็น placeholder ใน RFP ("setting the radius and tolerance time", RFP p20; "10–30 km" placeholder, RFP p23; "XX mins", RFP p25/p30). ค่าที่ต้องยืนยัน — ดู รัศมี Geofence สำหรับ off-site check-in และ open question เรื่อง threshold ที่ยังไม่กำหนด.
• "Mostly real-time updates" (RFP p20) เป็นถ้อยคำ SLA แบบมีเงื่อนไขของลูกค้าสำหรับ interface ของ DAS; queue-status update ทำงาน every 30 sec ขณะที่ integration event อื่น ๆ เป็น real-time (RFP p33; SUM p20). ดู DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration).
• Identity verification (facial scanning) ถูกระบุว่า โดยเฉพาะสำหรับ DL service (RFP p16); วิธีการที่แน่นอนยัง TBC (รอแนวทางจาก vendor) ตาม SUM p17.

Online Check-In — ข้อกำหนด generic / UX (matrix rows 1-19)

Compliance matrix ของ Online Check-In เริ่มด้วยกลุ่ม Generic ภายใต้แถบ "Operational / Functional features" — rows 1-12 on RFP p21 และ rows 13-19 on RFP p22. ส่วนนี้คือข้อกำหนด cross-cutting ด้าน platform, workflow และ UX ที่ driver app ต้องทำได้. stated (เอกสารเดียว; รายละเอียดเชิงลึกปรากฏเฉพาะใน RFP matrix). Parent: FR1 — Mobile Online Check-In สำหรับ driver.

Platform & workflow (RFP p21)

• รองรับทั้ง Android และ iOS รวมถึง mobile device ทุกรุ่น (row 1). ดู ความเข้ากันได้ของแพลตฟอร์ม responsiveness ภาษา และ branding.
• App รองรับ สอง workflow หลัก: Offsite Mobile Check-In processing ที่ validate ผ่าน geofencing และ trigger Gate-In events จาก queue management system เดิม (row 2).
• สำหรับ offsite option ฟีเจอร์ต้อง เปิด/ปิดใช้งานแบบ manual ได้โดย SCCC admin (row 3).
• App ต้องรองรับการ customize ขั้นตอนสำหรับ logistics service หลักสองแบบ: Delivery & Pick Up ออกแบบสำหรับ outbound logistics เป็นลำดับแรก โดยมีศักยภาพที่จะ scale up รองรับ scope เพิ่มเติมในอนาคต (row 4).

การจัดการ input และการควบคุม flow (RFP p21)

• Validate ข้อมูลที่ผู้ใช้กรอก และทำให้แน่ใจว่ามีข้อมูลที่จำเป็นครบก่อนอนุญาตให้เริ่ม check-in (row 5).
• สามารถ ย้อนกลับไปขั้นตอนก่อนหน้า ได้หากข้อมูลที่กรอกไม่ถูกต้อง [verbatim source: "in correct"] (row 6).
• ที่ขั้นตอน confirmation ผู้ใช้สามารถ ยกเลิกแบบ manual ได้ในขั้นตอนที่อนุญาต (ตาม business design) (row 7).
• เมื่อ transaction ล้มเหลวเพราะขาดเงื่อนไขที่จำเป็น app ต้อง ดำเนินการยกเลิกโดยอัตโนมัติ พร้อม pop-up แจ้งการยกเลิก (row 8).
• แสดง ข้อความ success หรือ error ที่ให้ข้อมูลเพื่อแนะนำผู้ใช้ (row 9).

Communication & navigation (RFP p21)

• มี in-app notification channel สำหรับการสื่อสารแบบ 1-way (SCCC admin → users) เพื่อกระจายข้อความ (row 10).
• มี in-app navigation ที่แนะนำผู้ใช้ผ่านแต่ละขั้นตอน ระบุขั้นตอนปัจจุบันและขั้นตอนถัดไป โดยใช้ colour code หรือ icon ที่เข้าใจง่าย — เช่น green = complete, red = current step, black = next step (row 11).
• สามารถ เก็บ geofencing ที่ตำแหน่งปัจจุบันของผู้ใช้ (row 12).

Alerts, integration & timeout (RFP p22)

• แสดง pop-up alert message / notification ภายใน app รวมถึงบน lock screen และ home screen ของผู้ใช้ (row 13).
• ตั้งค่า alarm หรือ reminder เพื่อให้รับทราบการดำเนินการ (row 14).
• สามารถ เชื่อมต่อและดึงข้อมูลแบบ real-time จาก queue management system เดิม เพื่อแสดงและ validate ข้อมูล/สถานะคิวระหว่างการดำเนินการ (row 15).
• เชื่อมต่อข้อมูลกับ transportation management system และ Queue Management system เดิม เพื่อรองรับการประมวลผลและ scheduling ตาม business requirement (row 16).
• Transaction timeout หากผู้ใช้กรอกข้อมูล (CI1) ไม่เสร็จภายในเวลาที่กำหนดตาม business requirement (adjustable / configurable) พร้อม pop-up message แจ้ง timeout (row 17).

Language & branding (RFP p22)

• รองรับ ภาษาไทย ด้วยรูปแบบ font ขนาดใหญ่ที่ชัดเจน configurable ได้ตามรูปแบบที่ SCCC corporate identity กำหนด (row 18).
• layout และหน้าจอของ application ปรับขนาดอัตโนมัติ เพื่อรองรับ font หลายขนาด (row 19).

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• ต้นฉบับมี grammar artifact ที่เก็บไว้ verbatim: row 6 "is in correct", row 11 "should use be in color codes".
• "CI1" (row 17) คือขั้นตอน check-in transaction; ระยะเวลา timeout เป็น configurable แต่ไม่ได้ระบุตัวเลขตายตัวใน RFP.
• คอลัมน์ vendor-response ทั้งสี่ (Fully / Partially / Not Compliant, Remarks) เป็น template เปล่าไว้ให้ผู้เสนอราคากรอก.

Online Check-In — การกรอกและตรวจสอบข้อมูล (shipment / truck / identity)

กลุ่ม "Data input & Verification", "Shipment information", "Truck Information" และ "Check-In Request" ของ Online Check-In matrix — rows 20-25 on RFP p22 และ rows 26-31 on RFP p23. ส่วนนี้กำหนดว่า driver app จะเก็บและ validate ข้อมูล shipment, RFID, truck และ driver identity เทียบกับ source systems ของ SCCC อย่างไรก่อนจะ request คิว. stated. Parent: FR1 — Mobile Online Check-In สำหรับ driver.

การเลือก Shipment-ID ตาม mode (RFP p22 row 20)

มีสอง mode:

• Delivery Mode (DL): เลือกได้จาก shipment ที่มอบหมายให้ driver คนนั้นเท่านั้น — "each driver ID seeing only their assigned shipments".
• Pick Up Mode (PK): กรอก shipment ID โดยตรง และ validate เทียบกับ TMS หรือ DAS ของ SCCC.

RFID, mobile-no & sync (RFP p22 rows 21-23)

• RFID: มีตัวเลือกให้ scan barcode บน RFID card หรือกรอก RFID No. เอง โดย validate เทียบกับข้อมูลที่ sync มาจาก DAS (row 21).
• การยืนยัน mobile no.: ผู้ใช้ต้องยืนยัน mobile no. ที่แสดง หากไม่ถูกต้อง/ไม่เป็นปัจจุบัน ให้แจ้งกรอกหมายเลขที่ถูกต้องก่อนดำเนินการต่อ (row 22).
• Auto-sync: sync และรับ รายละเอียด shipment / transaction แบบ real-time จากระบบ TMS และ INPLANT ของ SCCC โดยอัตโนมัติ และคงข้อมูลให้เป็นปัจจุบัน (row 23). ดู ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD.

Cross-validation & identity (RFP p22 rows 24-25; RFP p23 rows 26-28)

• Validate truck ID ระหว่าง ข้อมูล RFID กับรายละเอียด shipment (row 24).
• เมื่อ RFID, shipment No. หรือ truck ID ไม่ถูกต้อง ให้แสดง pop-up แจ้งข้อมูลที่ไม่ถูกต้องโดยอัตโนมัติ (row 25).
• มีตัวเลือกให้ re-select / re-input shipment หรือ RFID No. หรือยกเลิก การดำเนินการ (row 26).
• สำหรับ delivery shipments (DL) app ต้องมีฟีเจอร์ validate ตัวตนของ driver (เช่น face scanning, fingerprint scanning) (row 27). วิธีการถูก flag เป็น TBC (รอแนวทางจาก vendor) ตาม SUM p17 — ดู ช่องว่างของ PK Driver Master และวิธียืนยันตัวตนคนขับ (TBC).
• เก็บ geofencing ปัจจุบัน ของตำแหน่งผู้ใช้ และ validate ระยะห่างจากโรงงาน SRB; offsite check-in จะเปิดใช้ได้เฉพาะเมื่อผู้ใช้อยู่ในพื้นที่ที่อนุญาต — "Within defined radius e.g. 10-30 km from the SRB plant" (row 28, พิมพ์เป็นตัวเอียงสีแดง — placeholder range). ดู Master data dictionary (โค้ด dispatch/transport/weight/segment/item) และ FR1 — Mobile Online Check-In สำหรับ driver.

การแสดง Synced Shipment Info (RFP p23 row 29)

หลัง validate สำเร็จ ให้แสดง Shipment Information ที่ sync มาจาก DAS — fields เปลี่ยนแปลงได้ตาม material group (bag, bulk): Shipment No., Truck ID, Material Name, QTYs, Unit, Ship-to location, Text Note, etc.

การแสดง Synced Truck Info (RFP p23 row 30)

แสดง Truck Information ที่ sync มาจาก DAS พร้อม default values โดยให้ผู้ใช้แก้ไขบาง field ได้ ผ่านการเลือกจากรายการตัวเลือก — field ที่แก้ไขได้ต้อง configurable และเลี่ยงการกรอก free-text. Fields แตกต่างกันตาม material group:

• Bag: ประเภทรถ (e.g. 6W, 10W, 18W), น้ำหนักกฎหมาย, ลักษณะรถปูนถุง, ชนิดสินค้า / ชื่อสินค้า / น้ำหนัก, เงื่อนไขการรับสินค้า.
• Bulk: ประเภทรถ, น้ำหนักกฎหมาย, ประเภทรถปูนผง, ชนิดสินค้า / ชื่อสินค้า / น้ำหนัก, จำนวนฝาถัง, น้ำหนักการโหลด.

ชุด field ภาษาไทยและ code เหล่านี้ (6W/10W/18W, bag vs bulk) ถูกรวบรวมไว้ใน Master data dictionary (โค้ด dispatch/transport/weight/segment/item).

การยืนยัน Check-In Request (RFP p23 row 31)

หลัง validate shipment info & truck info แล้ว ให้แสดง confirmation page ที่ผู้ใช้เลือกได้ว่าจะ request check-in, กลับไปแก้ไขรายละเอียด หรือยกเลิก การดำเนินการ.

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• ค่า geofence "10-30 km" (row 28) เป็น placeholder range ("e.g.", ตัวเอียงสีแดง) — รัศมีจริงยัง TBC; ดู Master data dictionary (โค้ด dispatch/transport/weight/segment/item) และ open question เรื่อง geofence/tolerance.
• "DAS" ถูกอ้างเป็น source-of-truth สำหรับ shipment & truck info ที่ sync มา (rows 29-30); แต่การ validate shipment อาจไปที่ TMS ของ SCCC ก็ได้ (row 20) — ยืนยัน authoritative source ผ่าน ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD.
• การแยก material-group bag vs bulk เป็นตัวกำหนดชุด field ของ Shipment Info และ Truck Info ที่ต่างกัน.

Online Check-In — การจัดสรรคิว การแสดงผล การแจ้งเตือน และ loading document

กลุ่ม "Check-In Processing", "Queue data display", "Allocation", "Queue Notification" และ "Loading Document" ของ Online Check-In matrix — rows 32-43 on RFP p24 และ row 44 on RFP p25. ส่วนนี้ครอบคลุมสิ่งที่เกิดขึ้นหลัง check-in request สำเร็จ: การจัดสรรคิวที่ DAS, การแสดงคิว, gate-in barcode, tolerance window, การแจ้งเตือนเมื่อคิวถูกเรียก และ loading document. stated. Parent: FR1 — Mobile Online Check-In สำหรับ driver.

Queue request & sync (RFP p24 rows 32-33)

• เมื่อ check-in request สำเร็จ app ต้อง ส่ง queue request ไปยัง DAS เพื่อจัดสรรคิวโดยอัตโนมัติ (row 32).
• เมื่อยืนยันการจัดสรรสำเร็จ app ต้อง sync และรับ queue data จาก DAS โดยอัตโนมัติ เพื่อให้ได้ real-time automated updates (row 33). ดู DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration).

Queue data display (RFP p24 rows 34-37)

• แสดงข้อมูลคิวบน app: Queue No., Shipment ID, SKU (1st brand), Truck ID, Driver, Status (row 34).
• View-only ข้ามทุก platform: ผู้ใช้ดูข้อมูลคิวของ shipment ที่มอบหมายให้ตนได้ แม้จะ request check-in มาจากอีก platform (row 35).
• รับ queue update จาก DAS หลังคิวถูกเรียก และ populate gate-in time ล่าสุด (row 36).
• มี queue barcode หรือ QR code ให้ผู้ใช้ scan ที่ Gate-In เพื่อยืนยันการแสดง shipment info & truck detail (row 37).

Allocation & tolerance (RFP p24 rows 38-39)

• แสดง เวลาล่าสุดที่ผู้ใช้ได้รับอนุญาตให้มาถึงโรงงานเพื่อทำ full-loop Gate-IN ให้ครบภายใน tolerance time ที่กำหนด; หากผู้ใช้มาไม่ทันเวลา / ไม่อยู่ในช่วง window ดังกล่าว คิวจะถูกยกเลิกจาก DAS โดยอัตโนมัติ (row 38). ดู Threshold เวลา tolerance / window / overdue และ การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In.
• รับ update จาก DAS หลังกระบวนการ allocation เสร็จสมบูรณ์ (row 39).

Queue notification (RFP p24 rows 40-42)

• ส่ง pop-up message เมื่อคิวถูกเรียก — บน app, home screen และ lock screen (row 40).
• ข้อความ queue-notification "includes 3 parts" — แต่ RFP ให้มา สอง variant ที่ขัดแย้งกัน:
  • Row 41: (1) Your Queue is ready, (2) Link to mobile app for viewing loading documents, (3) Latest End time for entering the loading area.
  • Row 42: (1) Your Queue is ready, (2) Latest gate-in time, (3) disclaimer, (4) Link to mobile app for viewing loading documents — กล่าวคือ มี 4 bullet ทั้งที่ยังระบุว่า "3 parts". ประเด็นนี้เป็น internal inconsistency ที่ต้องเคลียร์ — ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน.

Loading document (RFP p24 row 43; RFP p25 row 44)

• รับ loading document จาก DAS มาแสดงบน app, Per DO, Max 11 DO (row 43).
• ข้อมูล loading ที่แสดงบน app (ภาษาไทย, RFP p25 row 44): เลขที่ใบขนสินค้า, ช่องจ่าย, ทะเบียนรถ, จำนวนคัน, รหัสลูกค้า, ชื่อลูกค้า, ชื่อผู้ขนส่ง, เลขที่ PreDO, ประเภทการขนส่ง, รูปแบบการจ่าย, เงื่อนไขการจัดส่ง, เลขที่ใบขน, เลขซีลปูนผง [reading uncertain — ILLEGIBLE], เลข RFID, วันที่เข้ารับสินค้า, Staff Text Note, เวลาที่ต้องเข้ารับสินค้า (Add in DAS), CPDO QR code, DO Barcode.

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• "SKU (1st brand)" (row 34) — ความหมายของ "1st brand" ยังไม่ชัด (brand สินค้าหลักบน DO?); ยืนยันกับ SCCC.
• ความไม่สอดคล้องของ notification "3 parts" (rows 41 vs 42) เป็น document-quality issue — ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน.
• threshold ของ tolerance/window-time ที่ควบคุม auto-cancel (row 38) ไม่ได้ระบุตัวเลขตายตัวตรงนี้; ตัวเลขที่ขับเคลื่อนการยกเลิกอยู่ที่ CI2 / parking-exit ใน RFP p25 — ดู Threshold เวลา tolerance / window / overdue.
• "เลขซีลปูนผง" (row 44) อ่านจาก source ที่ render มาได้ไม่แน่ใจ — ตรวจสอบกับ source PDF.

Online Check-In — การยกเลิก การจบรายการ ข้อมูล และ audit

กลุ่ม "Cancellation" และ "Data" ของ Online Check-In matrix — rows 45-54 on RFP p25 — รวมถึง logic การยกเลิกฝั่ง DAS / Online-CI ใน RFP p30 (rows 1-4) และ RFP p31 (row 5). ส่วนนี้กำหนด trigger ของการยกเลิก (เริ่มจากฝั่ง app, DAS และ admin), การจบ transaction, การส่งต่อ master data และการเก็บข้อมูลสำหรับ audit. stated. Parent: FR1 — Mobile Online Check-In สำหรับ driver.

กฎการยกเลิก (RFP p25 rows 45-50)

• ยกเลิกแบบ real-time จาก DAS หากผู้ใช้ไม่เข้าสู่ loading area ภายใน tolerance time ที่กำหนด — timestamp at parking exit − CI2 =< XX mins (row 45; "XX" เป็น placeholder ที่ยังไม่ได้กำหนดค่า — ดู Threshold เวลา tolerance / window / overdue).
• การยกเลิกที่เริ่มจาก app จะดำเนินการได้ เฉพาะเมื่อคิวยังไม่ถูกเรียก (CI2 not complete in DAS) (row 46).
• Re-input cancellation: หากยกเลิกเพื่อกรอกข้อมูลใหม่ ให้ส่งเฉพาะ transaction เพื่อ ยกเลิกคิว (cancel CI1 on DAS) (row 47).
• Receiving cancellation: ส่ง transaction เพื่อ ยกเลิกคิว (CI1) และยกเลิก gate-in ที่ DAS (row 48).
• SCCC admin สามารถ ยกเลิก check-in แบบ manual ได้ในกรณีที่มีการปรับข้อมูลจาก DAS โดยการอัปเดตจะสะท้อนไปยัง app (row 49).
• เมื่อมีการยกเลิก ให้ แสดงข้อความแจ้งการยกเลิก แก่ผู้ใช้ว่า transaction ของตนถูกยกเลิกแล้ว (row 50).

ข้อมูล การจบรายการ และ audit (RFP p25 rows 51-54)

• ส่งข้อมูล off-site check-in (เช่น shipment, truck ID) ไปยัง DAS เพื่อจัดเก็บเป็น master data ในแต่ละครั้งที่อัปเดต (row 51).
• เมื่อ โหลดสินค้าเสร็จ + รถ gate-out ให้รับข้อมูลจาก DAS เพื่อระบุว่า transaction เสร็จสมบูรณ์ ใน app หลังจากนั้น ผู้ใช้จะไม่สามารถดูหรือดำเนินการกับข้อมูลของ shipment นั้นได้อีก (row 52).
• เก็บข้อมูลย้อนหลังและ user logs ไว้ใน backup สำหรับ audit trail โดยมีระยะเวลาจัดเก็บขั้นต่ำ 1 ปี (row 53) — ต้นฉบับระบุ verbatim "1 years". ดู Application security (encryption, VA/PT, VAPT, SSL, IMC04).
• ส่งข้อมูล queue information ให้ DAS เพื่อใช้สร้าง report และ dashboard (row 54).

Logic ฝั่ง DAS สำหรับ Online-CI (RFP p30 rows 1-4; RFP p31 row 5)

ระบบใหม่ต้องขับเคลื่อน logic ต่อไปนี้ใน DAS (ครอบคลุมใน Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking) ด้วย):

• จัดเก็บข้อมูลคำขอ off-site check-in เป็น master file (p30 row 1).
• บันทึก timestamp ของ virtual Check-In จาก off-site service (p30 row 2).
• บันทึก timestamp ของการเรียกคิวแบบ off-site สำหรับการเดินทางมาถึงโรงงาน (p30 row 3).
• บันทึกเวลาที่ต้องใช้สำหรับ gate-in timestamp ตาม calculation logic เพื่อให้ มาถึงภายใน XX mins หลังการเรียกคิว (p30 row 4).
• ยกเลิกคิวหากไม่มี gate-in timestamp ภายในเวลาที่กำหนด หรือมีความล่าช้าจากเวลาเป้าหมาย; ในกรณีดังกล่าวจะมีการ ส่ง cancellation transaction ไปยัง mobile application เพื่อให้ผู้ใช้รับทราบ (p31 row 5).

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• "XX mins" (RFP p25 row 45; RFP p30 row 4) เป็น placeholder ที่ยังไม่ได้กำหนดค่าสำหรับ tolerance ของ parking-exit / การมาถึง — ดู Threshold เวลา tolerance / window / overdue.
• แยกความหมายของการยกเลิกเป็นสองแบบ: re-input cancel (ยกเลิกเฉพาะ CI1) กับ receiving cancel (ยกเลิก CI1 + gate-in) — rows 47-48.
• การเก็บข้อมูล audit "minimum 1 year" (row 53) เป็นค่าขั้นต่ำที่ลูกค้าระบุไว้ และเชื่อมโยงกับ security/data-protection — ดู Application security (encryption, VA/PT, VAPT, SSL, IMC04).

FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง

นี่คือ requirement หลัก (umbrella) ของฟีเจอร์เป้าหมายตัวที่สองจากสองตัวของ SCCC คือ Advanced Slot Booking สำหรับการรับปูนที่โรงงานสระบุรี (SRB) โดยปรากฏเป็น functional requirement No. 2 ในตาราง Functional Requirement ของ RFP — "Enable Advanced Slot Booking for customers/transporters … Feature on mobile or suitable platform for SCCC's customers or transporters admin to book a slot in advance for receiving cement at SRB plant. Users able to select their desired date and time. Once a booking is confirmed, users will receive the booking confirmation for reference and populate the booking ID on mobile app for driver to preview the information." (RFP p20, FR2, ref Use Case 2) นอกจากนี้ยังถูกระบุไว้แบบเต็มในรูปของ Use Case #2 (RFP p18-19) และเป็น target-state flow (RFP p14, SUM p13-14) ส่วนรายละเอียดในตาราง compliance matrix ถูกแยกไปอยู่ใน Advanced Slot Booking — slot status และ slot management, Advanced Slot Booking — booking confirmation, user profile และ customer quota และ Advanced Slot Booking — lifecycle, notifications และ cancellation

ผู้เกี่ยวข้อง (Actors) และช่องทาง (Channel)

• Actors = Users (Customers or transporter admin) (RFP p18) ยืนยันใน SUM p16 ("Advanced Slot Booking: Customer, transporter") และในรายงานการประชุม ("Target User คือลูกค้าและผู้ขนส่ง", MIN)
• Channel = mobile or other suitable platform — RFP ตั้งใจไม่จำกัดให้เป็น mobile อย่างเดียว (RFP p18, p20) ตัว mock-up ที่ให้มาเป็น Booking Website ที่แสดงผลบน desktop browser (RFP p14-15) และแถบ target-state ระบุ step 1 ว่า "Booking Website" อยู่ฝั่ง OUTSIDE (Customer site / Transporter Fleet) (SUM p13) ดังนั้นจึงคาดว่าการจองจะทำบน web/PC ซึ่งแยกจาก driver Mobile App ที่ใช้สำหรับ check-in — ดู Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor รายงานการประชุมยืนยันว่า "สามารถจองผ่าน Web หรือ App" (MIN)
• Plant scope = โรงงาน SRB / สระบุรี, งาน outbound logistics ("Cement dispatching for Domestic", RFP p12) ครอบคลุมปูน มอร์ตาร์ และ clinker ทั้งแบบถุงและบัลค์ ทั้งการส่งด้วยรถบริษัทและลูกค้ามารับเอง (MIN)

รายละเอียดและวัตถุประสงค์

"Enable advanced slot booking feature on mobile or suitable platform to allow customers or transporters to preserve advanced slot for receiving cement at plant under business condition & allowance." (RFP p18) เจตนาของ target-state คือ "Arrivals are planned in advance to reduce uncertainty and balance demand across plant capacity effectively." (SUM p13) ลูกค้าจองสล็อตออนไลน์ล่วงหน้า ขึ้นกับ booking policy (Timing / Slot availability / Cancellation allowance / Window Time) และต้องมี booking validation process ที่ GATE-In เพื่อให้แน่ใจว่าการจองนั้น valid (RFP p14, SUM p13) ดู พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)

เงื่อนไขก่อนเริ่ม (Preconditions) (RFP p18)

• ผู้ใช้ต้อง registered และต้อง login ก่อนดำเนินการ
• ผู้ใช้ต้องมี quota สำหรับการจอง ที่ใช้ได้ (ดู โมเดล Booking quota, Advanced Slot Booking — booking confirmation, user profile และ customer quota)
• slot master ต้องถูก maintain และ เปิดใช้งานในแต่ละ period เรียบร้อยแล้ว (ดู Advanced Slot Booking — slot status และ slot management)
• ผู้ใช้สามารถ จัดการรายละเอียดการจองของตนเองได้ภายใต้ business condition & allowances
• Interface ข้อมูลกับ DAS เพื่อ validation และอัปเดตสถานะ (ดู Booking Platform กับ Driver Mobile App — เป็นคนละระบบ/คนละ vendor, Advanced Slot Booking — lifecycle, notifications และ cancellation)
• Business users เป็นผู้รับผิดชอบในการจัดการ slot ที่เปิด, booking quota และ เปิด/ปิดการใช้งานฟีเจอร์ (เปิด/ปิดด้วยมือโดย SCCC admin, RFP p26 row3)

ขั้นตอนหลัก (Normal course) (RFP p18)

1. ผู้ใช้ log in
2. เลือกหรือกรอก shipment number หรือ field อื่นๆ ที่จำเป็น
3. เลือก slot ที่ว่างตาม วันและเวลาที่ต้องการ
4. อัปเดตข้อมูลที่เกี่ยวข้อง และระบบควร verify ความถูกต้อง
5. Confirm และทำ booking confirmation ให้เสร็จ
6. ระบบ สร้าง booking confirmation เป็นหลักฐาน ("as an evident" [sic], RFP p18)

ตัว web mock-up แสดงขั้นตอนนี้เป็น 5-step wizard (RFP p15): (1) กรอกข้อมูลชิปเม้นท์ (fill shipment info) → (2) เลือกวันเวลา (select date/time) → (3) อัพเดทข้อมูล (update info) → (4) ยืนยันการจอง (confirm booking) → (5) การจองเสร็จสมบูรณ์ (booking complete) รายละเอียดของ wizard, เนื้อหา confirmation และ quota อยู่ใน Advanced Slot Booking — booking confirmation, user profile และ customer quota

Postcondition และผลลัพธ์ (output)

• Postcondition: "After users receive booking confirmation, the slot will be booked" (RFP p18)
• Output = booking confirmation ที่เป็นหลักฐาน ซึ่ง "must be presented upon arrival at the SRB plant" (RFP p12) โดยมี unique booking ID พร้อม reference แบบ QR code / barcode (RFP p20, p27-28) ยืนยันด้วย action "Generate booking slip on each channel" ใน flow (SUM p14, RFP p14)
• เมื่อ confirm แล้ว booking ID จะถูก populate ขึ้นบน Mobile App ของคนขับเพื่อ preview (RFP p20) — booking platform จะ push booking confirmation ไปยัง online CI mobile app เพื่อให้คนขับเห็น booking reference (RFP p28 row30) นี่คือจุดเชื่อมสำคัญ (load-bearing link) ระหว่าง booking platform กับ driver app

ความถี่ในการใช้งานและ business logic หลัก (RFP p19)

• ความถี่ในการใช้งาน: รายวัน (Daily)
• Validate quota ของผู้ใช้ (ตาม sold-to หรือ ship-to หรือ fleet ต่อ วันหรือสัปดาห์) หาก quota ถึง limit/ถูก block ผู้ใช้จะใช้ฟีเจอร์ไม่ได้
• Validate slot availability เทียบกับ opened slot master ที่แนะนำโดย predefined algorithm หรือกำหนดโดย admin users หาก slot ที่ต้องการไม่ว่าง ให้ระบบแจ้งผู้ใช้เลือกใหม่
• ผู้ใช้ต้องมาถึงและ check-in ที่โรงงาน ภายใน tolerance time โดยใช้ booking ID ที่ระบบสร้างจาก platform
• Queue ของ advanced slot booking เป็น priority อันดับ 1 (ลำดับสูงสุดเทียบกับช่องทาง check-in อื่น) — ดู Flow Advanced Slot Booking แบบ To-Be (web booking → Gate-In validation → CI2) และหมายเหตุเรื่อง priority-conflict ด้านล่าง
• กรณี no-show ภายใน tolerance time การจองจะถูกยกเลิกและ slot ที่จองไว้จะถูกทำให้ว่าง แล้วเรียกคิวถัดไป (รายละเอียดใน Advanced Slot Booking — lifecycle, notifications และ cancellation)

หมายเหตุ / จุดที่ยังคลุมเครือ

• Priority conflict ที่ต้อง flag: RFP p19 ระบุว่า advanced slot booking เป็น "1st priority" ในขณะที่ RFP p17 (use case ของ Online Check-In) ระบุว่า off-site/kiosk/counter ใช้ priority เดียวกัน แบบ FCFS ตาม timestamp ที่ทำ CI1 เสร็จ ส่วน SUM p16 ปรับให้สอดคล้องกันว่า advanced bookings ถือครอง ส่วนที่กันไว้ (reserved) ของ slot capacity ส่วนที่เหลือให้บริการแบบ FCFS — แต่ลำดับ/สัดส่วนที่แน่ชัดยังไม่ได้ระบุเป็นตัวเลข เป็น open item ข้าม record (ดู โมเดล Booking quota และ open question เรื่อง queue-priority)
• ตัวเลข quota ปรากฏเฉพาะในรายงานการประชุม (จองล่วงหน้าได้ 3–7 วัน เช่น "ลูกค้า A อาจจองได้ไม่เกิน 3 เที่ยวต่อสัปดาห์" / ≤3 trips/week, MIN) ไม่มีในสไลด์ — ดู โมเดล Booking quota, พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)
• "as an evident" (RFP p18) เป็นการพิมพ์ผิดในต้นฉบับของคำว่า "as evidence" — ถอดความไว้เพื่อ traceability
• Source artifact ที่อ้างถึงใน RFP p14: "20230531_Online CL Bizflow Highlevel" PDF (high-level online cement-logistics flow ลงวันที่ 2023-05-31) — ยังไม่มีในมือ

Advanced Slot Booking — slot status และ slot management

รายละเอียดในแถวต่างๆ ของ compliance matrix ของ Advanced Slot Booking ครอบคลุมวิธีแสดง status ของ slot ให้ผู้ใช้ที่จอง และวิธีที่ business/operations admin ของ SCCC จัดการ slot inventory เป็น sub-requirement ของ FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง โดยฝั่ง admin เป็นของ ผู้ดูแล SCCC Operations / Business Admin

การแสดง slot status (RFP p27 row18, p28 rows 19-22)

• platform แสดงสถานะการจอง slot ปูน แยกตาม date & timeslot (RFP p27 row18)
• สถานะปัจจุบันของแต่ละ slot จะบ่งบอกว่า slot นั้น available, fully booked หรือ partially booked พร้อมตัวอย่าง colour codes (RFP p28 row19):
  • Green = Available for booking
  • Red = Fully booked / Reserved
  • Yellow = Partially booked (สีเหล่านี้ตรงกับ legend ของปฏิทินใน web mock-up บน RFP p15: 🟩 มีคิวว่าง = has available queue, 🟧 รอยืนยัน = awaiting confirmation, 🟥 คิวเต็ม = queue full, hatched = past/disabled date — หมายเหตุ: สไลด์ใช้สีส้มสำหรับ "awaiting confirmation" ในขณะที่ matrix ใช้สีเหลือง "partially booked" เป็นความต่างเล็กน้อยของถ้อยคำ)
• platform ควร แนะนำสถานะ availability ของ slot ในวันที่ต้องการ ให้ผู้ใช้ (RFP p28 row20)
• ต้องแสดง slot availability ใน รูปแบบที่ใช้งานง่าย (user-friendly) ให้ผู้ใช้ระบุและเลือก slot ที่ต้องการได้ง่าย (RFP p28 row21) — ย้ำจุดเน้นของ RFP โดยรวมเรื่อง user-friendliness และ visualisation ที่เรียบง่าย (RFP p11)
• ระหว่าง booking validation process platform ต้อง reserve slot ที่เลือกไว้เป็น PENDING เพื่อกันไม่ให้ลูกค้ารายอื่นเลือก slot เดียวกันพร้อมกัน (RFP p28 row22) — กล่าวคือเป็นการ hold เพื่อเลี่ยง double-booking race

การเลือก slot (RFP p28 row23)

• ผู้ใช้สามารถ เลือก date & time slot ที่ต้องการ จากตัวเลือกที่ว่างได้ (Group: "Slot booking", RFP p28 row23) mock-up แสดงเป็น grid slot ละ 30 นาที (13:30–17:30) พร้อม "จำนวนคิวว่าง" ต่อ slot (available-queue count เช่น 2) (RFP p15)

การจัดการ slot — admin (RFP p29 rows 37-44)

• เมื่อมี การยกเลิกหรือการเปลี่ยนแปลงใดๆ ใน slot platform จะอัปเดต slot availability และทำให้ slot ที่ถูกยกเลิก กลับมาว่าง ให้ผู้อื่นจองได้ (RFP p29 row37) — auto-release กลับเข้า inventory
• platform มี ฟีเจอร์ administrative ให้ SCCC จัดการ slot และ availability ด้วยมือ (RFP p29 row38)
• admin สามารถ เพิ่ม slot ใหม่, แก้ไข slot เดิม หรือลบ slot ออกจาก booking platform (RFP p29 row39)
• interface การจัดการ slot ให้ ความยืดหยุ่นในการปรับ slot availability ตาม business requirements (RFP p29 row40)
• รองรับ mass update ของ slot availability โดย SCCC admin เช่น update จาก Excel file (RFP p29 row41; สอดคล้องกับ requirement ทั่วไป "upload master data (Excel)", RFP p26 row8)
• รองรับการ แก้ไข slot duration ด้วยมือ เช่น เปลี่ยนจาก 2 hours per slot เป็น 3 hours per slot (RFP p29 row42) — slot period เป็นค่าที่ configurable
• รองรับการ คำนวณ logic ของ opened slot ตาม business design และ แนะนำจำนวน slot รวมสำหรับแต่ละ period เป็น guideline (RFP p29 row43) logic ของ opened-slot คำนวณจาก business input สามตัว (RFP p29 row44):
  1. Each Loading Type
  2. Each Product SKU
  3. Each Time slot

"predefined algorithm / opened slot master" นี้คือสิ่งที่ use case (RFP p19) และ constraint record โมเดล Booking quota อ้างถึง; ส่วน path override ที่ admin กำหนดเอง ("or admin users provide", RFP p19) เปิดให้ ผู้ดูแล SCCC Operations / Business Admin ป้อน slot ได้โดยตรง

หมายเหตุ / จุดที่ยังคลุมเครือ

• RFP p28 row19 รวม "Fully booked Reserved => Red" ไว้ในสีเดียว — ไม่ชัดว่า "Reserved" เป็น state ที่แยกจาก "Fully booked" หรือไม่ flag ไว้เพื่อขอความชัดเจน
• การคำนวณ opened-slot (Loading Type × Product SKU × Time slot) ระบุไว้เป็น guideline เท่านั้น; มันโต้ตอบกับ per-customer quota (sold-to/ship-to/fleet × day/week) อย่างไรนั้นอยู่ใน โมเดล Booking quota / Advanced Slot Booking — booking confirmation, user profile และ customer quota และยัง reconcile ไม่ครบในต้นฉบับ
• ตัวอย่าง slot-duration (2h→3h) บ่งชี้ว่า slot ไม่ได้ fixed-length; ค่า default slot period จริงไม่ได้ระบุไว้ที่นี่ — ดู พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)

Advanced Slot Booking — booking confirmation, user profile และ customer quota

รายละเอียดในแถวต่างๆ ของ compliance matrix ของ Advanced Slot Booking ครอบคลุม profile ของผู้ใช้ที่ทำการจอง, การ input ข้อมูลและ verification ที่เป็นด่านก่อนจองได้, artefact confirmation ที่ถูกสร้างเมื่อจองสำเร็จ และโมเดล customer quota เป็น sub-requirement ของ FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง โดยมี actor หลักคือ ผู้ดูแลฝั่ง Customer / Transporter (ผู้ใช้กลุ่ม Advanced Slot Booking)

User profile (RFP p27 rows 9-11)

แพลตฟอร์มแสดง user profile ที่ประกอบด้วย (RFP p27 row9):

• User account
• Contact person
• Booking quota ของผู้ใช้แต่ละราย แสดงเป็นสามค่า — Used, Remain, Total

นอกจากนี้ยังให้ผู้ใช้ ดูประวัติการจอง (booking history) ได้ พร้อมรายละเอียดการจอง ทั้งที่ผ่านมาและที่กำลังจะถึง (RFP p27 row10) SCCC จะได้รับ template สำหรับอัปเดต total user booking quota ในรูปแบบ master file (RFP p27 row11) — quota บริหารโดย SCCC ผ่านการอัปโหลด master-file ไม่ใช่ให้ลูกค้าแก้ไขเอง

การ input ข้อมูลและ verification (RFP p27 rows 12-17)

• Validate booking quota คงเหลือ หากผู้ใช้ ไม่มี quota เหลือ ระบบจะแสดง error message และบล็อกการจอง (RFP p27 row12) ดู โมเดล Booking quota
• รองรับการ กรอก Shipment ID ด้วยมือ และ validate กับ TMS หรือ INSEE+ ของ SCCC เพื่อยืนยันว่ามีอยู่จริง (RFP p27 row13) — ดู ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD
• Field ที่จำเป็นสำหรับ booking request (RFP p27 row14): Shipment No., Truck ID, Mobile No., Date & Timeslot
• หลัง validate สำเร็จ แสดง shipment information ที่ sync มาจาก DAS — field ที่อาจเปลี่ยนตาม material group (bag/bulk): Shipment No., Truck ID, Material Name, QTYs, Unit, Ship-to location, Text Note, ฯลฯ (RFP p27 row15)
• แสดง truck information ที่ sync มาจาก DAS พร้อมค่า default และให้ผู้ใช้อัปเดต เฉพาะบาง field โดยเลือกจาก list ของตัวเลือก — field ที่แก้ไขได้นั้น configurable และควรเลี่ยงการ free-text input (RFP p27 row16) field ของ Truck-Info ต่างกันตาม group: Bag = ประเภทรถ (เช่น 6W/10W/18W), น้ำหนักกฎหมาย, ลักษณะรถปูนถุง, ชนิดสินค้า/ชื่อสินค้า/น้ำหนัก, เงื่อนไขการรับสินค้า; Bulk = ประเภทรถ, น้ำหนักกฎหมาย, ประเภทรถปูนผง, ชนิดสินค้า/ชื่อสินค้า/น้ำหนัก, จำนวนฝาถัง, น้ำหนักการโหลด (RFP p27 row16)
• ข้อมูลที่จำเป็นทั้งหมดจาก shipment-info และ truck-info ต้อง สอดคล้องกันก่อนไปขั้นถัดไป (RFP p27 row17)

Booking confirmation workflow (RFP p28 rows 24-28)

• Confirmation workflow มีสองแบบ:
  • Automated booking confirmation ตาม business configuration setup เพื่อให้แน่ใจว่า slot ที่เลือกถูกจองสำเร็จ (RFP p28 row24)
  • Manual confirmation โดย SCCC admin สำหรับกรณีปรับพิเศษ ตาม flow ที่ business ออกแบบ (RFP p28 row25)
• เมื่อจองสำเร็จ ผู้ใช้จะได้รับ ข้อความ confirmation ในระบบ booking และทาง email พร้อมรายละเอียด slot ที่จอง (RFP p28 row26)
• ระบบสร้าง unique ID สำหรับแต่ละ booking request (RFP p28 row27) และ QR code หรือ barcode เป็น booking reference (RFP p28 row28)

เนื้อหา Confirmation — Customer vs Driver (RFP p28 rows 29-30)

Customer confirmation (RFP p28 row29) ประกอบด้วย:

• Booking reference no.
• Booking QR / Booking Barcode
• Customer Profile → Customer name/ID, Contact No.
• Booking Detail → Booked Date & Time slot, Product Name, Commodity (Bag/Bulk), QTY
• Terms and condition (Booking policy ของ SCCC)

Driver confirmation (RFP p28 row30): booking platform จะ ส่ง booking confirmation ไปยัง online CI mobile application เพื่อให้คนขับแสดง booking reference ได้ เนื้อหาเหมือนเวอร์ชันลูกค้า แต่ตัด block Customer Profile ออก (Booking reference no.; Booking QR/Barcode; Booking Detail [Date & slot, Product Name, Commodity, QTY]; T&C) นี่คือการ realise แบบรูปธรรมของ "populate the booking ID on mobile app for driver to preview" (RFP p20) — จุดเชื่อมสำคัญระหว่าง FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง กับ driver app

Web wizard แสดง flow ของ confirmation เป็น 5-step process (RFP p15): fill shipment info → select date/time → update info → confirm booking → booking complete

Customer quota (RFP p30 rows 48-49)

• รองรับการ เก็บและคำนวณ customer quota อัตโนมัติ ตาม configuration ของ SCCC จาก input เหล่านี้ (RFP p30 row48):
  • Total opened slot for each period
  • Customer level
  • Customer ID
  • Product
  • Period (Shipment per Day, week, month)
• รองรับให้ SCCC admin ปรับ customer quota ด้วยมือ ได้ (RFP p30 row49)

การ auto-calculation นี้จับคู่กับมิติ quota ใน use case (ตาม sold-to / ship-to / fleet ต่อ วันหรือสัปดาห์, RFP p19) และตัวอย่างตัวเลขในรายงานการประชุม (≤3 trips/week ต่อลูกค้า, advance window 3–7 วัน, MIN) — โมเดลเต็มอยู่ใน โมเดล Booking quota

หมายเหตุ / จุดที่ยังคลุมเครือ

• โมเดล quota ถูกอธิบายไว้สองแบบ — แบบ sold-to/ship-to/fleet × day/week (RFP p19) เทียบกับแบบ customer level/ID/product × shipment-per-day/week/month (RFP p30 row48) ทั้งสองทับซ้อนกันแต่ไม่เหมือนกันเป๊ะ ต้อง reconcile ใน โมเดล Booking quota
• การ validate shipment ทำได้กับ TMS หรือ INSEE+ ก็ได้ (RFP p27 row13) แต่ไม่ได้ระบุว่าตัวไหนเป็น authoritative — ดู ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD
• การแยกตาม material-group (Bag vs Bulk) เป็นตัวกำหนดชุด field ของ shipment/truck ที่ต่างกันตลอดทั้ง flow (RFP p27 rows 15-16)

Advanced Slot Booking — lifecycle, notifications และ cancellation

รายละเอียดในแถวต่างๆ ที่ครอบคลุม lifecycle ของการจอง — notifications/reminders, การ handshake check-in ที่หน้างาน, เส้นทางการยกเลิก, สถานะการจอง, การจัดการการจอง — รวมถึง logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อนสำหรับช่องทาง Advanced Slot Booking เป็น sub-requirement ของ FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง โดยพฤติกรรมฝั่ง DAS เป็นคู่ขนานด้านการจองของ Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking) และเชื่อมต่อผ่าน DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration)

Notifications & reminders (RFP p29 row31)

booking platform จะส่ง advance notifications และ reminders ไม่ว่าจะ ภายใน booking platform หรือทาง email เพื่อแจ้งผู้ใช้เกี่ยวกับ slot ที่จองไว้ และ ในกรณีที่มีการเปลี่ยนแปลงหรือยกเลิก (RFP p29 row31, Group "Booking Notification (Customer)")

การประมวลผล check-in ที่หน้างาน (RFP p29 row32)

ที่โรงงาน คนขับสแกน Booking QR code / barcode เพื่อดำเนินการ check-in ที่ SRB plant หลัง check-in เสร็จใน DAS สถานะการจองจะถูก mark เป็น completed ใน booking platform (RFP p29 row32) ซึ่งเป็นการปิด loop ระหว่าง check-in ฝั่งเกทกับ record การจอง

การยกเลิก (Cancellation) (RFP p29 rows 33-36)

• platform มี ฟีเจอร์ cancellation ที่ให้ผู้ใช้เริ่มการยกเลิกได้ และ บันทึกเหตุผลการยกเลิกและ action ที่ทำ ตาม booking policy ของ SCCC (RFP p29 row33) ดู พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)
• ลูกค้ายกเลิกเอง (self-cancel): ลูกค้ายกเลิก booking request ของตนได้เมื่อจำเป็น ตาม business cancellation policy (RFP p29 row34)
• SCCC admin ยกเลิก: SCCC admin ยกเลิกการจองได้สำหรับการปรับใดๆ ที่ต้องการ (RFP p29 row35)
• ยกเลิกอัตโนมัติ (Automated cancel): workflow การยกเลิกอัตโนมัติจะ trigger หากไม่ได้รับสัญญาณ check-in completion จาก DAS ภายในเวลา slot ที่จอง (RFP p29 row36) ซึ่งย้ำอีกครั้งในฝั่ง DAS (RFP p31 row16): คิวจะถูกยกเลิกหากไม่มี gate-in timestamp ภายใน reserved timeslot หรือล่าช้ากว่า reserved time — จะมีการ ส่ง cancellation transaction ไปยัง booking platform เพื่อ mark การจองเป็น canceled และส่ง notification ให้ผู้ใช้รับทราบ (สอดคล้องกับกฎ no-show ใน RFP p19: no-show ภายใน tolerance time → ยกเลิกการจอง, slot ถูกทำให้ว่าง, เรียกคิวถัดไป; และ action "Delay → Auto cancel booking ID" ใน flow, SUM p14)

สถานะการจองและการจัดการการจอง (RFP p29 rows 45-47)

• แสดง รายละเอียดการจองให้ลูกค้า บน booking platform (RFP p29 row45)
• ลูกค้าไม่สามารถแก้ไขรายละเอียดการจองเองแบบ self-service ได้ (RFP p29 row46) — เป็น view-only; การเปลี่ยนแปลงต้องผ่านการ cancel/rebook หรือผ่าน admin
• Booking status ที่ configurable ได้ (RFP p29 row47): Open / Pending / Confirm / Complete / Cancel

Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน — Advanced Slot Booking (RFP p31-32, rows 14-23)

ตาราง compliance matrix ของ Functional Requirement ระบุสิ่งที่ระบบต้องทำให้ DAS ทำสำหรับช่องทางการจอง:

• เก็บ booking data เป็น master file สำหรับแต่ละวัน รวมถึง Booking ID, Truck ID, Shipment, Product (SKU) (RFP p31 row14)
• Log เวลาที่ใช้สำหรับ gate-in timestamp อิงตาม reserved timeslot (RFP p31 row15)
• คิวถูก auto-cancelled หากไม่มี gate-in timestamp ภายใน / ล่าช้ากว่า reserved timeslot → cancellation transaction ไปยัง booking platform + user notification (RFP p31 row16, ตามข้างต้น)
• Verify Truck ID จากข้อมูล booking request โดยเทียบกับ Truck ID ที่ scan ได้ตอน gate-in (RFP p32 row17)
• Verify booking confirmation (RFP p32 row18)
• Verify gate-in time & Truck ID & booking confirmation; หาก validation ผ่าน → ทำ automated Check-In 1 & Check-In 2 (RFP p32 row19)
• verification เดียวกัน แต่ถ้า ก่อน reserved time → automated CI1 เท่านั้น; ถ้า อยู่ในช่วง reserved time → automated CI2 (RFP p32 row20)
• Dashboard (Advanced slot Visibility): เพิ่ม dashboard ใน DAS เพื่อ monitor รถที่อยู่นอกโรงงานซึ่งขอ advanced slot booking ในแต่ละวัน อ้างอิงตามรายงาน Product Monitoring page — แยกตาม product (SKU), log reserved time (RFP p32 row21)
• Report (Product Monitoring Page): ปรับแต่งเพื่อระบุว่า transaction ไหนมาจาก service ไหน — เพิ่มคอลัมน์ "Source channel" หนึ่งคอลัมน์ และ แยกแต่ละ service ด้วยสี (RFP p32 row22)
• Report (Outbound Weight Bri[d]ge) — รายงาน outbound weighbridge (RFP p32 row23; "Bride" เป็นการพิมพ์ผิดในต้นฉบับของ "Bridge"/weighbridge)

รายการ dashboard/report เหล่านี้ทับซ้อนกับ FR3 — Dashboard & reporting สำหรับทีม operations; booking data ยังถูกป้อนเข้า DAS เพื่อสร้าง report/dashboard ด้วย (RFP p30 row52)

หมายเหตุ / จุดที่ยังคลุมเครือ

• auto-cancel window ผูก lifecycle ของการจองเข้ากับ DAS check-in ภายในเวลาของ slot แต่ tolerance/window time จริงยังไม่ได้ระบุเป็นตัวเลข (placeholder "XX mins" ในแถว DAS Online-CI, RFP p30 row4 / p31 row10) ดู พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)
• logic การแยก CI1/CI2 ของการจอง (ก่อน vs อยู่ในช่วง reserved time, RFP p32 row20) สอดคล้องกับ logic ของ Online-CI (queue-called vs not) — ทั้งคู่ realise ใน DAS และเป็นความรับผิดชอบของระบบที่ต้องขับเคลื่อน; ดู Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking)
• typo "Outbound Weight Bride" ปรากฏซ้ำทั้งใน RFP p31 และ p32 ถอดความตามต้นฉบับ

FR3 — Dashboard & reporting สำหรับทีม operations

ข้อกำหนด functional หลักข้อที่สามของ SCCC: mobile app หรือ platform ที่เหมาะสม ซึ่งให้ทีม operations มี dashboard และ reporting ครบถ้วนเพื่อ monitor การดำเนินงานได้อย่างมีประสิทธิภาพ (RFP p20, FR#3, ref Use Cases 1 & 2). confirmed — ระบุไว้ใน FR table และขยายความผ่าน compliance matrix กับกลุ่ม DAS อีกทั้งมีแรงผลักจาก pain point ด้าน Operational Efficiency ของสถานะปัจจุบันใน SUM p7.

Headline requirement (RFP p20)

FR#3: "Provide dashboard & reporting for operations team — Mobile app or suitable platform that provides a comprehensive dashboard and reporting capabilities for the operational team to effectively monitor operations." กลุ่มผู้ใช้คือ SCCC operations / business admin — ดู ผู้ดูแล SCCC Operations / Business Admin.

Reporting ใน booking platform (RFP p25-26; RFP p30)

• มี dashboard หรือ report ของ queue-information ใน booking platform — Daily, Weekly, Monthly (RFP p26 row 55).
• ส่ง ข้อมูล queue information ให้ DAS เพื่อใช้สร้าง report และ dashboard (RFP p25 row 54).
• SCCC admin เข้าถึง raw data สำหรับ report และ analytics เพื่อให้ได้ insight เรื่อง usage และ performance (RFP p26 row 56; RFP p30 row 53).
• Customer booking-quota report ให้ SCCC ใช้ monitor — Daily, Weekly, Monthly (RFP p30 row 54).
• ข้อมูล advanced-booking เป็น Daily & Weekly planning report สำหรับ booking request แยกตามแต่ละ product (RFP p30 row 55).

Dashboard & report ฝั่ง DAS (RFP p31-32)

ระบบใหม่ต้องเพิ่มสิ่งต่อไปนี้ใน DAS (ครอบคลุมใน Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking) ด้วย):

• Dashboard — Off-site Visibility (RFP p31 row 11): เพิ่ม dashboard ใน DAS เพื่อ monitor รถที่อยู่นอกโรงงานซึ่ง request off-site check-in; อ้างอิงกับ report ของ Product Monitoring page; แยกตาม product (SKU); บันทึก timestamp ของแต่ละ activity (Virtual CI1, Virtual Call the queue).
• Dashboard — Advanced-slot Visibility (RFP p32 row 21): เพิ่ม dashboard ใน DAS เพื่อ monitor รถที่อยู่นอกโรงงานซึ่ง request advanced slot booking ในแต่ละวัน; แยกตาม product (SKU); บันทึก reserved time.
• Report — Product Monitoring Page (RFP p31 row 12 / p32 row 22): customize report เพื่อระบุว่า transaction ใดมาจาก service ใด — เพิ่มคอลัมน์หนึ่งเพื่อบันทึก "Source channel" และ แยกแต่ละ service ด้วยสี.
• Report — Outbound Weighbridge (RFP p31 row 13 / p32 row 23): "Report (Outbound Weight Bride)" [verbatim — น่าจะหมายถึง "Weighbridge"].

Business driver (SUM p7)

Dashboard เหล่านี้ตอบโจทย์ผลกระทบด้าน Operational Efficiency ของสถานะปัจจุบันโดยตรง: "Inefficient dispatching and resource utilization due to limited advance visibility of incoming trucks" (SUM p7). ประโยชน์ของ To-Be คือการมองเห็นรถที่กำลังเข้ามาล่วงหน้า รองรับการบาลานซ์ demand/supply และการบริหารทรัพยากร. Baseline load ที่ใช้ sizing: 1000 SH/DAY, 100% Check-In, 40% in peak time, peak ≈ 15:00–19:00, max 77 trucks/hr at Gate-In, max 78 drivers/hr at Check-In (SUM p7).

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• platform ระบุไว้กว้าง ๆ ว่า "mobile app หรือ suitable platform" (RFP p20) — ปล่อย form factor ให้ vendor; ลูกค้าสนใจความสามารถด้าน dashboard/report ไม่ใช่ channel.
• คอลัมน์ "Source channel" + การ colour-coding (RFP p31/p32) รองรับการวิเคราะห์ multi-channel queue arbitration โดยตรง — ดู Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ.
• "Outbound Weight Bride" ปรากฏซ้ำในทั้งสองกลุ่มโดยไม่มีรายละเอียด — ยืนยันเนื้อหาของ weighbridge report กับ SCCC.

FR5 — ปรับปรุงการแสดงคิวบนจอ TV ที่อาคาร check-in ของ SRB

ข้อกำหนด functional ข้อที่ห้าของ SCCC: "Improve queue display on the TV screen at SRB check-in building" (RFP p20, FR#5, ref Use Cases 1 & 2). stated — หัวข้ออยู่ใน FR table แต่ scope รายละเอียดไม่ได้ขยายความในหน้าที่ extract มา และแถว FR#5 ถูกตัดท้ายที่ด้านล่างของ RFP p20.

Headline requirement (RFP p20)

FR#5: "Improve queue display on TV screens at SRB check-in building — Improve queue display on the TV screen at SRB check-in building" — แถวนี้ต่อไปยังหน้าถัดไปและ ถูกตัดท้ายที่ด้านล่างของ RFP p20 [text truncated in source]. แมปกับ Use Cases 1 และ 2 (Online Check-In + Advanced Slot Booking).

สิ่งที่มีอยู่ในปัจจุบัน (SUM p6)

ข้อกำหนดนี้ต่อยอดจาก DAS queue-display board เดิม ที่อาคาร check-in ของ SRB (SUM p6). board ปัจจุบันแสดง:

• คอลัมน์แยกตาม product เช่น อินทรีเพชร ปอร์ตแลนด์ประเภท 1 ใน ถุง (bag) และ ผง (powder/bulk) รวมถึง variant "ถุง 1 ตัน" (jumbo-bag).
• แถบ "คิวที่เรียก" (queue being called) ด้านบนที่แสดงทะเบียนที่ถูกเรียกพร้อม DL / PK badge (เช่น กท73-2363 [DL], พย80-9168 [PK]).
• ในแต่ละคอลัมน์: มี sub-row สีแดงแสดง "รถทั้งหมด" (total trucks) + "Window Time" ตามด้วยรายการทะเบียนที่รอ ซึ่งแต่ละคันติด DL (dark-red) หรือ PK (green) badge.

board, kiosk, counter และ card reader เดิมถูกรวบรวมไว้ใน ฮาร์ดแวร์เดิมในโรงงาน — kiosk, counter, card reader, ALPR, DAS display board.

การตีความ

[INFERRED] การปรับปรุงนี้น่าจะหมายถึงการนำเสนอ multi-channel queue + window time ให้ชัดเจนขึ้นบนจอ TV ภายในอาคาร (สอดคล้องกับ channel ใหม่อย่าง Online Check-In และ Advanced Slot Booking ที่ป้อนเข้า DAS). เนื้อหาการแสดงผลและ hardware เป้าหมายที่แน่นอนไม่ได้ระบุในหน้าที่ extract มา.

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• แถว FR#5 ถูกตัดท้ายใน RFP p20 — ข้อความ requirement ฉบับเต็มอยู่ในหน้าถัดไป (ไม่อยู่ใน extract นี้); ยืนยันถ้อยคำฉบับสมบูรณ์. ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน.
• FR#5 เป็นหนึ่งในสอง FR (อีกตัวคือ FR#4 real-time integration) ที่แตะ hardware/จอภาพของโรงงานเดิม แทนที่จะเป็น mobile/booking app ใหม่ — ยืนยันเนื้อหาการแสดงผลและ hardware กับ SCCC.
• Window Time และ DL/PK channel badge เกี่ยวข้องกับ multi-channel queue arbitration — ดู Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ และข้อกำหนดด้าน reporting FR3 — Dashboard & reporting สำหรับทีม operations.

User account, registration & login (ทั้งสอง app)

ข้อกำหนด "User Login" ของทั้งสองผลิตภัณฑ์ — Online Check-In app (RFP p26 rows 57-61) และ Advanced Slot Booking platform (RFP p30 rows 56-60) — รวมถึง NFR ด้าน access-management ที่เป็น cross-cutting (RFP p37) และ Key Business Logic เรื่องรูปแบบ login ของ driver (SUM p16). stated.

Online Check-In app — User Login (RFP p26 rows 57-61)

• Self-service registration บัญชีผู้ใช้ พร้อม verification workflow ที่ integrate กับ DID (row 57). ดู ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD.
• เก็บข้อมูลผู้ใช้ภายใน application (row 58).
• 1 user account ต่อ 1 driver ID ทั้ง delivery & pick-up mode; หาก ใช้ driver ID เดียวกันทั้ง DL & PK ให้ทำเป็น รูปแบบบัญชีแยก หรือ workflow ที่แยกกันภายใต้บัญชีเดียวกัน (row 59). ดู คนขับ DL (Delivery / รถ Company-Fleet), คนขับ PK (Pick-up / ลูกค้ามารับของเอง).
• Self-service password reset (row 60).
• ฟีเจอร์ Remember-password (row 61).

Advanced Slot Booking platform — User Login (RFP p30 rows 56-60)

• กระบวนการ registration ที่ สร้างบัญชีและรับ customer profile จาก INSEE+ (row 56). ดู ผู้ดูแลฝั่ง Customer / Transporter (ผู้ใช้กลุ่ม Advanced Slot Booking), ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD.
• Secure login ด้วย email / mobile ที่ลงทะเบียน และ password (row 57).
• Self-service password reset (row 58).
• ฟีเจอร์ Remember-password (row 59).
• ระหว่าง registration ผู้ใช้ระบุ name, email address, contact detail และรายละเอียดอื่นที่จำเป็น (row 60).

Key Business Logic — รูปแบบ login ของ driver (SUM p16)

• DL Driver: ต้อง log on & verify ตัวตน โดยใช้ unique user ID.
• PK Driver: ยังไม่ต้อง verify ตัวตน ณ ตอนนี้ และ รูปแบบ login ยัง TBC เพราะ SCCC ยังไม่มีการจัดการ PK Driver Master ในปัจจุบัน. ช่องว่างนี้เป็น open item — ดู ช่องว่างของ PK Driver Master และวิธียืนยันตัวตนคนขับ (TBC).

Access management & authorization (RFP p37)

• SCCC internal users provision ผ่าน sync จาก MS AD (Active/Account Directory) (row 37).
• External users บริหารผ่าน unique Name/User ID โดยใช้ email หรือ username (row 36).
• Authorization scoping: "drivers should see and operate only shipments/tasks under the specific customer" (row 39) — multi-tenant / scoping แยกตามลูกค้า. ดู การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO.

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• DID คือ target ของ verification-workflow integration สำหรับการลงทะเบียน driver (RFP p26 row 57); ความหมายที่แน่นอน (Digital ID / Driver ID service) ไม่ได้ขยายความใน extract — ยืนยันผ่าน ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD.
• ช่องว่าง PK Driver Master (SUM p16) เป็น blocker สำคัญของรูปแบบ login ฝั่ง PK และยังไม่ resolve — ดู ช่องว่างของ PK Driver Master และวิธียืนยันตัวตนคนขับ (TBC).
• booking platform ดึง customer profile จาก INSEE+ (RFP p30 row 56) ขณะที่ driver ลงทะเบียนผ่าน DID (RFP p26 row 57) — เป็น identity source สองแหล่งที่ต่างกันระหว่างสองผลิตภัณฑ์.

Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking)

RFP มีกลุ่มข้อกำหนด "DAS" โดยเฉพาะ — rows 1-4 on RFP p30, rows 5-13 on RFP p31 (Online CI) และ rows 14-23 on RFP p31-32 (Advanced Slot Booking) — ซึ่งอธิบาย logic ที่ต้อง เพิ่ม/ขับเคลื่อนในระบบ DAS queue-management เดิม ด้วย solution ใหม่. stated. DAS เดิมคือ integration hub — ดู DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration).

Logic Online CI ใน DAS (RFP p30 rows 1-4; RFP p31 rows 5-10)

• จัดเก็บข้อมูลคำขอ off-site check-in เป็น master file (p30 row 1).
• บันทึก timestamp ของ virtual Check-In จาก off-site service (p30 row 2).
• บันทึก timestamp ของการเรียกคิวแบบ off-site สำหรับการเดินทางมาถึงโรงงาน (p30 row 3).
• บันทึกเวลาที่ต้องใช้สำหรับ gate-in timestamp ตาม calculation logic เพื่อให้ มาถึงภายใน XX mins หลังการเรียกคิว (p30 row 4).
• ยกเลิกคิวหากไม่มี gate-in timestamp ภายในเวลาที่กำหนด หรือล่าช้าจากเป้าหมาย; ส่ง cancellation transaction ไปยัง mobile app เพื่อให้ผู้ใช้รับทราบ (p31 row 5).
• เก็บ shipment หรือ truck ID จาก off-site service พร้อมความสามารถ filter ตามวันที่ปัจจุบัน (p31 row 6).
• Verify truck ID จากข้อมูลคำขอ off-site โดย เทียบกับ truck ID ที่ scan ได้ที่ gate-in (p31 row 7).
• Verify gate-in time & Truck ID; หาก validation ผ่าน → automated Check-In 1 & Check-In 2 (p31 row 8).
• หาก validation ผ่านแต่ยังไม่มีการเรียกคิว → automated CI1; หลังเรียกคิว → automated CI2 (p31 row 9).
• เพิ่ม logic เพื่อ validate เวลาที่ผ่าน parking exit ภายใน XX mins หลังทำ CI2 เสร็จ; หากล่าช้า → ยกเลิกคิวใน DAS และส่ง transaction ไปยัง mobile app เพื่อให้รับทราบ (p31 row 10).

ส่วนนี้คือคู่ฝั่ง DAS ของกฎการยกเลิกฝั่ง app ใน Online Check-In — การยกเลิก การจบรายการ ข้อมูล และ audit; logic two-stage CI1/CI2 + การมาถึง gate-in มีรายละเอียดใน การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In.

Dashboard & report ของ Online CI ใน DAS (RFP p31 rows 11-13)

• Dashboard (Off-site Visibility): monitor รถที่อยู่นอกโรงงานซึ่ง request off-site check-in; แยกตาม product (SKU); บันทึก timestamp ของ Virtual CI1 และ Virtual Call the queue (row 11).
• Report (Product Monitoring Page): เพิ่มคอลัมน์ "Source channel"; แยกแต่ละ service ด้วยสี (row 12).
• Report (Outbound Weighbridge) [verbatim "Outbound Weight Bride"] (row 13).

(รายการเหล่านี้ปรากฏใน FR3 — Dashboard & reporting สำหรับทีม operations ด้วย.)

Logic Advanced Slot Booking ใน DAS (RFP p31 rows 14-16; RFP p32 rows 17-23)

• จัดเก็บ booking data เป็น master file ของแต่ละวัน รวมถึง Booking ID, Truck ID, Shipment, Product (SKU) (p31 row 14).
• บันทึกเวลาที่ต้องใช้สำหรับ gate-in timestamp ตาม reserved timeslot (p31 row 15).
• ยกเลิกคิวหากไม่มี gate-in timestamp ภายใน reserved timeslot หรือล่าช้าจากเวลาที่จองไว้; ส่ง cancellation transaction ไปยัง booking platform เพื่อ mark สถานะ booking เป็น canceled และแจ้งผู้ใช้ (p31 row 16).
• Verify truck ID จากข้อมูลคำขอ booking เทียบกับ truck ID ที่ scan ได้ที่ gate-in (p32 row 17).
• Verify booking confirmation (p32 row 18).
• Verify gate-in time & Truck ID & booking confirmation; หาก validation ผ่าน → automated CI1 & CI2 (p32 row 19).
• หาก validation ผ่านแต่ยังก่อน reserved time → automated CI1; หากอยู่ภายใน reserved time → automated CI2 (p32 row 20).
• Dashboard (Advanced slot Visibility): monitor รถที่อยู่นอกโรงงานซึ่ง request advanced slot booking ในแต่ละวัน; แยกตาม product (SKU); บันทึก reserved time (p32 row 21).
• Report (Product Monitoring Page): คอลัมน์ "Source channel" + แยกสีตาม service (p32 row 22); Report (Outbound Weighbridge) (p32 row 23).

ส่วนนี้คือคู่ฝั่ง DAS ของกฎ booking lifecycle/cancellation ใน Advanced Slot Booking — lifecycle, notifications และ cancellation.

หมายเหตุด้าน integration และเชิงพาณิชย์ (SUM p20; MIN)

Integration matrix (SUM p20; RFP p33) ระบุ interface ของ DAS ที่ logic เหล่านี้ต้องพึ่งพา: shipment data (DAS→Mobile App, real-time), data validation (Mobile App→DAS, real-time), Check-In 1 & 2 update (Mobile App→DAS, real-time), queue status update (DAS→Mobile App, every 30 sec), cancel event (Mobile App→DAS, real-time) และ booking confirmation (Platform→DAS, real-time). ตาม meeting minutes vendor ต้องเสนอราคารวมทั้ง API และการปรับแต่ง DAS ในข้อเสนอ ("Vendor ต้องเสนอราคารวมทั้ง API และการปรับแต่งระบบ DAS ในข้อเสนอ", MIN) และการเชื่อม platform ใหม่เข้ากับ DAS เดิมอาจมีค่าใช้จ่ายเพิ่ม (ที่ยังคาดไม่ถึง).

หมายเหตุ / ประเด็นที่ยังไม่ชัดเจน

• "XX mins" (p30 row 4; p31 row 10) และ "within XX km radius / within XX hours" (RFP p32 additional notes) เป็น placeholder ที่ยังไม่กำหนดค่า — เป็นค่าที่ admin configurable ได้ ให้ SCCC เป็นผู้กำหนด.
• กลุ่ม DAS ของ Online CI และ Advanced Slot Booking มีโครงสร้างสะท้อนกัน (verify truck ID, two-stage auto CI1/CI2, auto-cancel, visibility dashboard, Product Monitoring report, weighbridge report) แต่ผูกกับ anchor คนละตัว: off-site queue call กับ reserved timeslot.
• ความเป็นเจ้าของ สัญญา และต้นทุนของ DAS-integration เป็น open commercial question — DAS เป็นระบบภายในเดิม และ platform ใหม่อาจเป็นคนละ vendor (MIN; SUM p20).