รัศมี Geofence สำหรับ off-site check-in

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

Off-site Mobile Online Check-In ถูกควบคุมด้วย geofence: คนขับจะเริ่ม check-in (CI1) จากนอกโรงงานได้ ก็ต่อเมื่อตำแหน่ง GPS บนมือถืออยู่ภายในรัศมีที่ยอมรับได้จากโรงงาน SRB (Saraburi) เท่านั้น นี่เป็นเงื่อนไขเบื้องต้นที่บังคับของทั้งฟีเจอร์ — หากการตรวจรัศมีไม่ผ่าน การ check-in นอกพื้นที่ก็จะใช้งานไม่ได้

• precondition ของ use-case ระบุว่าฟีเจอร์จะเปิดใช้งาน "when drivers is surrounded at SRB plant (Validate the geofencing of mobile GPS)" (RFP p16)
• functional matrix กำหนดให้แอปต้อง "capture the current geofencing of the user's location & validate the distance from SRB plant. Offsite check-in should enable if the user is within the allowed area" (RFP p23 row 28)
• flow แบบ To-Be กำหนดให้รัศมีเป็น decision gate แรก: "Radius valid? NO → Feature not available" (SUM p12) และ "The System will validate the current location of driver using GPS from their mobile device to determine if they are within the accepted radius" (SUM p11)
• นอกเหนือจากการเป็น gate แล้ว รัศมียังใช้เพื่อ ประเมินเวลาที่คนขับจะมาถึงโรงงานหลังจากถูกเรียกคิว ด้วย — SUM p18 นิยาม logic ของ "Radius" ว่า "To defined available distance to enable offsite mobile Check-In and estimated time to arrive at plant after queue calling" ดู Threshold เวลา tolerance / window / overdue เพิ่มเติมด้วย (logic เรื่อง delayed-GI / window ขึ้นอยู่กับการประเมินเวลามาถึงนี้)

ค่านี้ยังไม่ถูกกำหนดตายตัว (ต้องปรับได้โดย admin)

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

• RFP p23 row 28 — "(Within defined radius e.g. 10-30 km. from the SRB plant)" พิมพ์เป็น ตัวเอียงสีแดง (สไตล์ placeholder/เน้น) สังเกตว่านี่เป็น ช่วงที่มี "e.g." กล่าวคือเป็นตัวอย่างประกอบ ไม่ใช่ค่าที่ยืนยันแล้ว
• RFP p32 (Additional notes) — "flexible configuration of booking conditions, such as defined radius and time window … (e.g., within XX km radius …)" คำว่า "XX km" เป็น placeholder ที่ยังไม่ได้เติมค่า
• RFP p20 row 1 (FR1) — แอปต้องเปิดให้ "configurability, such as setting the radius and tolerance time" ซึ่งยืนยันว่ารัศมีเป็นพารามิเตอร์ที่ admin ตั้งค่าได้ ไม่ใช่ค่า hard-code
• SUM p18 — เซลล์ค่า/ด้านขวาของแถว "Radius" ว่างเปล่า (ยังไม่ระบุค่าบนสไลด์)
• MIN (line 20) — "คนขับสามารถเช็คอินผ่านมือถือเมื่ออยู่ภายในรัศมีที่กำหนด (เช่น 30 กิโลเมตร)" = check-in ผ่านมือถือเมื่ออยู่ภายในรัศมีที่กำหนด เช่น 30 km — อีกครั้งที่เป็นเพียงตัวอย่าง ไม่ใช่ requirement ที่กำหนดตายตัว

ดังนั้นตัวเลขที่กระจายอยู่ตามเอกสารต่างๆ จึงไม่สอดคล้องกัน: ช่วงตัวอย่าง "10–30 km" (RFP p23), "XX km" ที่ยังไม่นิยาม (RFP p32), ค่าว่าง (SUM p18), และตัวอย่าง "30 km" (MIN) ทั้งหมดเป็นเพียงตัวอย่างประกอบ; ค่าที่ใช้จริงใน production ยังไม่ได้ข้อสรุปและ SCCC ต้องการให้ admin ปรับค่าได้ ช่องว่างเชิงตัวเลขที่ยังเปิดอยู่นี้ติดตามไว้ใน ค่า threshold เชิงตัวเลขที่ยังไม่ได้กำหนด — geofence radius และ tolerance/window time

ภาพประกอบสนับสนุน

SUM p18 วาง screenshot Google Maps ของพื้นที่สระบุรี ไว้ใต้แถว logic ของ Radius พร้อม pin ที่มีป้ายภาษาไทยระบุจุดรับสินค้า/ปั๊มน้ำมันใกล้เคียงรอบโรงงาน (ปูนนครหลวง, PTT Station ปั๊มปตท.ทับกวาง, การสุวรรณ, เสริมสินไพบูลย์, บุญญฤทธิ์, ลิ้มยงเส็ง, มีนา, ฯลฯ) แผนที่นี้ เป็นเพียงภาพประกอบ — ไม่มีการวาดวงรัศมีหรือ scale bar [INFERRED purpose: convey the geofence concept and the spread of driver origin/rest points] จึงไม่ได้ระบุค่ากิโลเมตรเช่นกัน

หมายเหตุของผู้วิเคราะห์

• รัศมีมีสองวัตถุประสงค์: (1) เป็น eligibility gate สำหรับ off-site CI1 และ (2) เป็น input ของ การประเมินเวลามาถึง ที่ป้อนเข้า logic เรื่อง delayed-Gate-In / window-time ใน Threshold เวลา tolerance / window / overdue การเปลี่ยนรัศมีจึงส่งผลทั้งต่อว่าใครจะ check-in ได้ และต่อพฤติกรรมของ threshold การมาถึงเร็ว/ช้า
• เนื่องจากค่านี้เป็นตัวกำหนด trade-off ด้านความปลอดภัย/throughput (เล็กเกินไป = แทบไม่ได้ประโยชน์จากการล่วงหน้า; ใหญ่เกินไป = การประเมินเวลามาถึงไม่น่าเชื่อถือ) SCCC จึงต้องสรุปค่าเริ่มต้นก่อนเริ่ม build — flag ไว้ใน ค่า threshold เชิงตัวเลขที่ยังไม่ได้กำหนด — geofence radius และ tolerance/window time

Threshold เวลา tolerance / window / overdue

กลุ่มของ timing threshold เป็นตัวกำหนดว่าคิวจะยังคงสถานะ valid ตลอดกระบวนการ check-in สองขั้น (ดู การ Check-In สองขั้น (CI1 / CI2) และ logic การมาถึงที่ Gate-In) หรือไม่ SCCC ต้องการให้เกือบทั้งหมด ปรับได้โดย admin และในเอกสารต้นทาง ส่วนใหญ่ยังเป็น placeholder ("XX") — มีเพียงตัวเลขเดียวที่เป็นรูปธรรม (Parking exit = 30 mins) ที่ยืนยันแล้ว และแม้กระทั่งค่านั้นก็ยังถูกไฮไลต์ว่าเป็นค่าชั่วคราว ค่าตัวเลขที่ยังไม่นิยามถูกติดตามไว้ใน ค่า threshold เชิงตัวเลขที่ยังไม่ได้กำหนด — geofence radius และ tolerance/window time

1. Gate-In arrival window (tolerance time)

หลังจาก CI1 คนขับต้อง มาถึงโรงงานและ Gate-In ภายใน tolerance/window time โดย validate เทียบกับ Gate-In timestamp:

• "Users have to arrive at plant within tolerance time; if they arrive outside the window time, the queue will be rejected (Compare with Gate-In Time stamp)" (RFP p17)
• แอปต้อง "display the latest time by which the user is allowed to arrive … to complete the full-loop Gate-IN within the specific tolerance time. If the user fails to arrive on time or window time, the queue should be automatically canceled from DAS" (RFP p24 row 38)
• "The queue will be canceled if the gate-in timestamp is missing within the required time or if there is a delay from the target time" (RFP p31 row 5)
• logic การมาถึงเพื่อ Gate-In (SUM p18): Prior → TBC, Ontime → Automated CI1 & CI2, Delay → Cancel Queue สาขา "Prior" (มาถึงก่อนเวลา) ระบุชัดว่ายังไม่สรุป ("TBC")
• การจัดการกรณีมาถึงก่อนเวลา (RFP p17): หากผู้ใช้มาถึง ก่อน window time จะ "must pass through the gate normally and wait for check-in 2 to be completed when the queue is called."
• Delayed GI (offsite) = XX mins — SUM p17 ระบุค่านี้ไว้ใต้ "Out-off window time" โดยค่าถูก ไฮไลต์สีเหลืองเป็น placeholder (TBD) นี่คือ tolerance เชิงตัวเลขสำหรับการมาถึงนอกพื้นที่ที่ล่าช้า และยังไม่ได้กำหนด

2. Lead time ของการแจ้งเตือนก่อนเรียกคิว

ก่อนการเรียกคิว แอปจะแจ้งเตือน (pop-up ในแอป, banner ที่หน้า home, pop-up ที่หน้า lock screen) เงื่อนไข trigger คือ "prior queue call XX mins" และ "queue call" (SUM p12) lead time "XX mins" ยังไม่นิยาม (สถานะคิวเองรีเฟรชตามรอบ 30 วินาที — SUM p17 — แต่นั่นเป็น polling interval ไม่ใช่ tolerance)

3. Threshold การเกินกำหนดออกจากจุดจอด (Parking-exit overdue)

หลังจาก CI2 รถต้องผ่านจุดออกจากที่จอด (parking exit) ภายในขีดจำกัด overdue โดยวัดเป็น Parking-exit timestamp − CI2 timestamp:

• "If the parking exit exceeds the overdue time (Based on the time stamp of Check-In 2 and Parking Exit), the queue will be rejected or put on hold" (RFP p17)
• "Receive real-time transaction cancellation from DAS if the user does not enter the loading area within the specific tolerance time (timestamp at parking exit − CI2 =< XX mins)" (RFP p25 row 45)
• "Add a logic to validate the time to pass the parking exit within XX mins after completing check-in 2. If delayed, cancel the queue in DAS & send the transaction to mobile application for user acknowledgement" (RFP p31 row 10)
• SUM p17 กำหนด Parking exits = 30 mins — เป็นค่าเดียวที่เป็นรูปธรรม แต่ถูก ไฮไลต์สีเหลือง (ยังเป็นค่าชั่วคราว ไม่ได้สรุปสุดท้าย) ส่วน RFP ยังคง threshold เดียวกันไว้เป็น "XX mins" (ไม่นิยาม) จึงมีความไม่ตรงกันระดับเอกสารว่า 30 mins ยืนยันแล้วหรือไม่

4. CI1 transaction timeout

หากผู้ใช้ไม่กรอกข้อมูล CI1 ให้เสร็จทันเวลา transaction จะ timeout:

• "Transaction timeout, if user not complete information (CI1) within time based on business requirement (able to adjust). Ability to pop up message regarding transaction timeout" (RFP p22 row 17)
• สะท้อนอีกครั้งใน SUM p17: "Transaction timeout (user not complete info – CI1 within time), able to re-select shipment?" (เครื่องหมาย "?" ท้ายข้อความบ่งชี้ว่าเป็นประเด็นออกแบบที่ยังเปิดอยู่ — ว่าผู้ใช้จะเลือก shipment ใหม่ได้หรือไม่หลัง timeout) ค่านี้ปรับได้; ไม่ได้ระบุค่าเริ่มต้น

5. Booking arrival tolerance (channel advanced-booking)

สำหรับ channel Advanced Slot Booking การมาถึงจะถูกตรวจเทียบกับ reserved timeslot แทนที่จะเป็น window ที่ได้จาก CI1:

• "Truck GI Time Tolerance = ±1H?" — SUM p19 booking-logic matrix แสดงเป็น สีแดง (ยังไม่สรุป)
• "The queue will be canceled if the gate-in timestamp is missing within the reserved timeslot or if there is a delay from the reserved time" (RFP p31 row 16); ยกเลิกอัตโนมัติหากไม่ได้รับ check-in completion จาก DAS ภายในช่วงเวลา booking slot (RFP p29 row 36)
• การดำเนินการเมื่อผิดเงื่อนไข: Auto cancel booking (เลือกไว้) หรือ Deduct booking quota (SUM p19) ดูรายละเอียดฝั่ง booking ใน พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก) และ โมเดล Booking quota

หมายเหตุของผู้วิเคราะห์

• ทุก threshold ข้างต้นเป็นพารามิเตอร์ และ SCCC ต้องการการตั้งค่าแบบ no-code สำหรับ master/business process อย่างชัดเจน (RFP p34 NFR #10) การ build ไม่สามารถดำเนินต่อได้หากยังไม่มีค่าเริ่มต้นที่ยืนยันแล้ว
• ค่าที่ยังไม่นิยามที่ค้างอยู่: Delayed-GI tolerance (XX mins), pre-call alert lead time (XX mins), parking-exit overdue (RFP "XX mins" เทียบกับ SUM "30 mins" ที่ยังชั่วคราว), CI1 timeout, และ booking ±1H tolerance ทั้งหมดรวมไว้ใน ค่า threshold เชิงตัวเลขที่ยังไม่ได้กำหนด — geofence radius และ tolerance/window time
• สาขา early-arrival ("Prior → TBC") เป็น business rule ที่ยังไม่ได้ข้อสรุป ไม่ใช่แค่ตัวเลขที่หายไป — ควรยืนยันว่ารถที่มาถึงก่อน window จะถูกจัดลำดับอย่างไรเทียบกับรถที่มาตรงเวลา

พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก)

"booking policy" คือชุดกฎที่ควบคุมฟีเจอร์ Advanced Slot Booking (ดู FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง, Flow Advanced Slot Booking แบบ To-Be (web booking → Gate-In validation → CI2)) โดย SUM p13 อธิบายไว้ตาม 4 มิติ ได้แก่ Timing / Slot availability / Cancellation allowance / Window Time และระบุว่าลูกค้าจะ "book a slot online in advance, depending on the booking policy" พร้อมกับมี "a booking validation process … required at the GATE-In to ensure that the booking is valid." พารามิเตอร์ที่เป็นรูปธรรมถูกระบุไว้ใน booking-logic matrix ของ SUM p19 โดยมีรายละเอียดสนับสนุนใน RFP compliance matrix และ meeting minutes ทั้งนี้ SCCC ต้องการให้ค่าทั้งหมดปรับได้โดย admin (no-code) ค่าที่แสดงด้านล่างจึงเป็น policy intent ตามที่ระบุไว้ ซึ่งหลายรายการยังถูกทำเครื่องหมายว่ายังไม่สรุป

พารามิเตอร์ตามที่ระบุไว้ (SUM p19 booking-logic matrix เว้นแต่ระบุเป็นอย่างอื่น)

• Booking System Available Time = 24H — แพลตฟอร์มการจองเปิดให้ใช้งานตลอด 24 ชั่วโมง
• Booking Slot Period = 1H — ความละเอียดของ slot โดยค่าเริ่มต้นคือ 1 ชั่วโมง ปรับได้: admin สามารถ "manually modify the time slot, such as changing it from 2 hours per slot to 3 hours per slot" (RFP p29 row 42) (ข้อความใน RFP อ้างถึง 2h→3h ขณะที่ค่าเริ่มต้นใน SUM matrix คือ 1H — ควรยืนยันค่าเริ่มต้นที่ถูกต้อง)
• Allow Booking Time (advance lead-time window) — ยังไม่สรุป matrix แสดงสองตัวเลือกที่แข่งกันอยู่และเป็น สีแดง ทั้งคู่ ได้แก่ "Prior 2–168H?" หรือ "Prior 24–168H?" (168H = 7 วัน) ขอบล่าง (2H หรือ 24H) ยังไม่ได้ข้อสรุป และ RFP p32 ยังเปิดให้ตั้งค่าเป็น "no minimum advance time required" ได้ด้วย ส่วน MIN (line 29) ระบุการจองล่วงหน้า 3–7 วัน ("จองล่วงหน้าได้ 3-7 วัน") ซึ่งขอบล่าง (3 วัน = 72H) ไม่ตรงกับตัวเลือกใดใน matrix ความขัดแย้งนี้ติดตามไว้ใน ช่วง lead-time การจองล่วงหน้า (Advance-booking) ยังไม่ได้ข้อสรุป
• Booking Confirmation = Yes (เลือกไว้) — ต้องมีขั้นตอนการยืนยันเสมอ
  • Booking Confirmation By = System (Auto) หรือ Human (Manual) — รองรับทั้งสองแบบ RFP p28 rows 24–25 กำหนดให้มีทั้ง workflow การยืนยันแบบอัตโนมัติ (ขับเคลื่อนด้วย business-config) และ workflow การยืนยันแบบ manual โดย SCCC admin สำหรับกรณีปรับแก้พิเศษ
  • Booking Confirmation Channel = Booking System หรือ E-Mail — เมื่อสำเร็จ ผู้ใช้จะได้รับข้อความยืนยัน "in booking system and email" (RFP p28 row 26)
• Window Time / arrival tolerance — รถที่จองไว้ต้อง "Arrive at SRB factory by window time" (SUM p13) ค่า tolerance ของการมาถึงตามการจองคือ "Truck GI Time Tolerance = ±1H?" (SUM p19, สีแดง/ยังไม่สรุป) การดำเนินการเมื่อเกินกำหนด = Auto cancel booking (เลือกไว้) หรือ Deduct booking quota รายละเอียดเรื่องเวลาอยู่ใน Threshold เวลา tolerance / window / overdue

เงื่อนไขเบื้องต้นและข้อห้ามของการจอง

• Booking Prerequisite = Completed shipment — การจองทำได้เฉพาะกับ shipment ที่ completed แล้วเท่านั้น (SUM p19; สอดคล้องกับ flow ใน RFP p18-19: validate ว่ามี shipment อยู่จริงก่อนเลือก slot)
• ไม่อนุญาต: การจองด้วย used shipment, การจอง during GICI [INFERRED: Gate-In/Check-In in progress], และการจองด้วย shipment ของผู้อื่น ("Booking With Other's Shipment = Not Allow") (SUM p19) คำว่า GICI ไม่ได้นิยามไว้ในสไลด์ — flag ไว้สำหรับ glossary อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations)
• Specify Channel For Booking = Need — การจองต้องผูกกับ channel ที่เฉพาะเจาะจง (เชื่อมโยงกับคำถามเรื่องการแยก truck-ID ตาม channel; ดู โมเดล Booking quota)

นโยบายการยกเลิก

• Booking Cancellation By SCCC = Reserve right — SCCC สงวนสิทธิ์ในการยกเลิกการจองใดๆ; admin สามารถยกเลิกเพื่อปรับแก้ได้ (RFP p29 row 35)
• Booking Cancellation By Customer = ≥12H (แสดงเป็นสีแดง/ตัวหนา, SUM p19) — ลูกค้ายกเลิกเองได้เฉพาะเมื่อ ล่วงหน้าอย่างน้อย 12 ชั่วโมง ก่อนถึง slot "in accordance with the business cancellation policy" (RFP p29 row 34) การยกเลิกต้อง บันทึกเหตุผลและการดำเนินการที่เกิดขึ้น (RFP p29 row 33)
• การยกเลิกอัตโนมัติ: หากไม่ได้รับการ check-in completion จาก DAS ภายในช่วงเวลา slot ที่จองไว้ ระบบจะยกเลิกการจองอัตโนมัติและปล่อย slot กลับคืนสู่สถานะว่าง (RFP p29 rows 36–37)

ลำดับความสำคัญ / capacity ที่กันไว้

• คิวของ advanced booking มี ลำดับความสำคัญสูงสุด (1st priority): "Queue of advanced slot booking is the 1st priority" (RFP p19) และบน queue track จะถือ capacity แบบ Reserved ภายใน slot ขณะที่ Online/Kiosk/Counter แบ่ง capacity ส่วนที่เหลือแบบ FCFS ตามเวลา CI1-completion (SUM p16) การจัดลำดับข้าม channel มีรายละเอียดใน Logic การเดินคิวรวมหลายช่องทาง (multi-channel) และลำดับความสำคัญ
• กรณี no-show ภายใน tolerance, "the booking will be canceled and the booked slot will be marked as available. The next queue will be called" (RFP p19)

หมายเหตุของผู้วิเคราะห์

• Status = stated: พารามิเตอร์ส่วนใหญ่มีระบุไว้เป็นลายลักษณ์อักษร แต่มีสามรายการที่ระบุชัดว่ายังไม่สรุป (ขอบของ Allow Booking Time, ค่า ±1H GI tolerance, และขอบ ≥12H ของการยกเลิกโดยลูกค้าซึ่งเป็นสีแดง/ตัวหนา = อยู่ระหว่างพิจารณา) อีกทั้งตัวเลข advance-window ยังขัดแย้งกันระหว่าง SUM p19 กับ RFP p32 กับ MIN — ดู ช่วง lead-time การจองล่วงหน้า (Advance-booking) ยังไม่ได้ข้อสรุป
• "Booking policy" ยังถูกอ้างถึงในรูปของ Terms & Conditions block ที่แสดงให้ผู้ใช้เห็นในหน้ายืนยันการจอง ("Terms and condition (SCCC's Booking policy)", RFP p28 rows 29–30) ซึ่งหมายความว่านโยบายนี้ต้องถูกแสดงให้ลูกค้าเห็น ไม่ใช่บังคับใช้เฉพาะฝั่ง server เท่านั้น
• มีไอคอน Excel workbook ที่เชื่อมโยงไว้พร้อมคำบรรยาย "Booking Policy" อยู่บน SUM p19 — สเปรดชีตนโยบายฉบับจริงเป็นไฟล์ภายนอกที่ยังไม่มีในมือ (ดู เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ)

โมเดล Booking quota

booking quota จำกัดปริมาณที่ลูกค้า/transporter สามารถจองได้ในฟีเจอร์ Advanced Slot Booking (ดู Advanced Slot Booking — booking confirmation, user profile และ customer quota, ผู้ดูแลฝั่ง Customer / Transporter (ผู้ใช้กลุ่ม Advanced Slot Booking)) ถือเป็นเงื่อนไขเบื้องต้นของการจอง — "Users have an available quota for booking" (RFP p18) — และถูก validate ตั้งแต่ต้น: "if the user does not have quota left, the system will display an error message" พร้อมบล็อกการจอง (RFP p27 row 12) quota เป็นส่วนหนึ่งของ booking policy ในภาพรวม พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก) แต่แยกบันทึกไว้ที่นี่เพราะมี basis, unit, การจัดเก็บ และกลไกการปรับโดย admin เป็นของตัวเอง

Basis และ unit ของ quota (SUM p19 booking-logic matrix)

• Booking Limit (basis) — quota กำหนดได้ตาม Sold-To, Ship-To, หรือ Transporter ("Validate user quota (by sold-to or ship-to or fleet per day or week)", RFP p19)
• Quota Unit — Shipment per Day / Week / Month / Year (SUM p19; RFP p30 row 48 ระบุ Period = "Shipment per Day, week, month")

การคำนวณอัตโนมัติจาก configuration ของ SCCC (RFP p30 row 48)

แพลตฟอร์มต้อง "automatically store and calculate customer quotas based on SCCC configuration" โดยขับเคลื่อนจาก:

• Total opened slot for each period
• Customer level
• Customer ID
• Product
• Period (Shipment per Day, week, month)

ดังนั้น quota จึงไม่ใช่ตัวเลขแบนๆ ตัวเดียว — แต่คำนวณต่อ customer × product × period เทียบกับ total opened-slot capacity ส่วน opened-slot capacity เองก็คำนวณจาก business input (Each Loading Type, Each Product SKU, Each Time slot — RFP p29 row 44) ซึ่งเชื่อม quota เข้ากับชุดโค้ดใน Master data dictionary (โค้ด dispatch/transport/weight/segment/item)

การมองเห็นในระดับผู้ใช้ (RFP p27)

• หน้า user profile แสดง Booking quota ของผู้ใช้แต่ละรายเป็น Used / Remain / Total (row 9)
• ผู้ใช้ดู booking history ได้ (การจองที่ผ่านมาและที่กำลังจะถึง) (row 10)

การดูแล total quota โดย SCCC

• SCCC อัปเดต total user booking quota ผ่าน master-file template ("Provide a template for SCCC to update the total user booking quota as a master file", RFP p27 row 11)
• admin สามารถ ปรับ manually quota ของลูกค้าได้ ("Ability to manually adjust customer quotas by SCCC admin", RFP p30 row 49)
• quota ถูกติดตามผ่าน customer booking quota report (Daily / Weekly / Monthly) สำหรับ SCCC (RFP p30 row 54)

ตัวอย่างการใช้งาน — ชีต "Booking Quota Planning" (SUM p19)

screenshot Excel ที่ฝังไว้ ลงวันที่ 01-Aug-22 (เป็นตัวอย่าง/เทมเพลต ไม่ใช่นโยบายที่ใช้จริง) แสดงตัวอย่าง grid ของ quota:

• Header: Item Type = BK, Plant = 2, Sub Plant / Channel / M/C / Material = All
• ตารางย่อย "Booking Quota Allowance (No. of truck in each hour)" ครอบคลุมคอลัมน์ชั่วโมง 0–23
• Allowance ≈ 5 trucks per hour per channel (เซลล์ "5" สีเขียว ส่วนใหญ่อยู่บน BK01–BK03, material RMX)
• มิติที่พบ: Plant 2, sub-plant K3 / K4, channel BK01–BK09, material RMX / IDUM / Quick Cast, โค้ด tank BULK21–BULK34 (ความหมายของโค้ด → Master data dictionary (โค้ด dispatch/transport/weight/segment/item))

การยืนยันจาก meeting minutes (MIN)

• "มีโควต้าการจองในแต่ละช่วงเวลา" — มี booking quota สำหรับแต่ละช่วงเวลา (line 30)
• ตัวอย่างกฎ: "ลูกค้า A อาจจองได้ไม่เกิน 3 เที่ยวต่อสัปดาห์" — ลูกค้า A จองได้ ≤ 3 เที่ยวต่อสัปดาห์ (line 33) — เป็นตัวอย่างเพดานต่อลูกค้าที่สอดคล้องกับ unit "Shipment per Week"
• Q&A ยืนยัน planning intent: "มีการวางแผนว่าโรงงานไหน ช่วงเวลาไหน สินค้าอะไร ให้จองได้กี่คัน" — วางแผนตาม plant × ช่วงเวลา × product ว่าจองรถได้กี่คัน (line 70) ซึ่ง map ตรงกับมิติของ config ใน RFP p30 row 48

quota ในฐานะเครื่องมือลงโทษ

เมื่อรถที่จองไว้มาถึงนอกช่วง Gate-In tolerance การดำเนินการเมื่อผิดเงื่อนไขปรับได้ระหว่าง "Auto cancel booking" (ค่าเริ่มต้นที่เลือกไว้) กับ "Deduct booking quota" (SUM p19) — กล่าวคือ quota อาจถูกหัก/ลงโทษแทนที่จะเพียงปล่อย slot คืน ดู Threshold เวลา tolerance / window / overdue

หมายเหตุของผู้วิเคราะห์

• Status = stated: โครงสร้าง, มิติ และกลไก admin ของ quota model ถูกระบุไว้เป็นลายลักษณ์อักษร; มีเพียงตัวเลข allowance เฉพาะที่เป็นค่าตัวอย่าง/เทมเพลต (5 trucks/hr บนชีตตัวอย่างปี 2022; ≤3 เที่ยว/สัปดาห์ สำหรับ "customer A")
• ตัวเลข quota ฉบับจริงอยู่ในไฟล์ Excel "Booking Policy" ภายนอกที่อ้างถึงใน SUM p19 — ยังไม่มีในมือ (ดู เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ)
• "fleet" (RFP p19) กับ "Transporter" (SUM p19) ดูเหมือนจะเป็น quota basis เดียวกันที่ใช้สองชื่อ — ควรยืนยันการตั้งชื่อ

Master data dictionary (โค้ด dispatch/transport/weight/segment/item)

ระบบใช้ชุดของ code lists / master-data classifications ทั่วทั้งระบบเพื่ออธิบาย shipment, รถ, สินค้า และ channel ต่างๆ โดยปรากฏชัดที่สุดใน booking-logic matrix ของ SUM p19 และรายการ truck-info field ใน RFP (RFP p23 row 30, RFP p27 row 16) โค้ดเหล่านี้เป็นตัวขับเคลื่อนการตัดสินใจเรื่อง scope, การคำนวณ quota (โมเดล Booking quota) และการเลือกชุด field โดยมีหลายโค้ดที่ มีค่าระบุไว้แต่ไม่มีการนิยามความหมาย ในเอกสารที่มีอยู่ — dictionary ฉบับเต็มเป็นไฟล์ Excel ภายนอก (ดู เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ); คำย่อที่ยังไม่นิยามถูกติดตามไว้ใน อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations) ด้วย

ชุดโค้ดการจัดประเภท (SUM p19 matrix — เขียว = เลือกไว้/อยู่ใน scope, เทา = อยู่นอก scope)

• DispatchType → Outbound (อยู่ใน scope, เขียว) | Inbound (นอก scope, เทา) | Backhaul (นอก scope, เทา) ยืนยันขอบเขต scope "Outbound only" (SUM p10; ดู ขอบเขตและขอบเขตงาน — อะไรอยู่ใน / นอก scope)
• TransportType → DL (delivery / การขนส่งโดย company-fleet) | PK (pick-up / ลูกค้ามารับเอง) ทั้งคู่อยู่ใน scope ("Delivery & Pick Up", RFP p21 row 4) สอดคล้องกับตัวเลือกบน kiosk อินทรีจัดส่ง (INSEE delivery = DL) กับ อินทรีรับของเอง (INSEE self-pickup = PK) และ badge DL/PK บนบอร์ด DAS (SUM p6)
• WeightType → โค้ด 001 | 002 | 004 | 888 | 999 | 101 ความหมายไม่ได้นิยามไว้ในต้นทาง [ILLEGIBLE/undefined — ต้องใช้ data dictionary]
• MarketSegment → Domestic | Border | Export
• ItemType → BG (Bag) | BK (Bulk) | CL (Clinker) | BB (undefined) BG/BK/CL อนุมานจากบริบท (bag/bulk/clinker); BB ยังไม่ระบุ [INFERRED gaps — ควรยืนยัน]

การแยกตามวัสดุ / บรรจุภัณฑ์: Bag กับ Bulk

ระบบแยกชุด field ของ shipment และรถตาม material group: Bag กับ Bulk (ผง) อยู่บ่อยครั้ง — "fields are subject to change by material group (bag, bulk)" (RFP p23 row 29, RFP p27 row 15) ชุด field ของ truck-info จึงต่างกันตามนั้น (RFP p23 row 30 / RFP p27 row 16):

Bag truck fields:

• ประเภทรถ (truck type — e.g. 6W, 10W, 18W)
• น้ำหนักกฎหมาย (legal/permitted weight)
• ลักษณะรถปูนถุง (bagged-cement truck body characteristics)
• ชนิดสินค้า, ชื่อสินค้า, น้ำหนัก (product type, product name, weight)
• เงื่อนไขการรับสินค้า (goods-receipt conditions)

Bulk truck fields:

• ประเภทรถ (truck type)
• น้ำหนักกฎหมาย (legal weight)
• ประเภทรถปูนผง (bulk/powder-cement truck type)
• ชนิดสินค้า, ชื่อสินค้า, น้ำหนัก (product type, name, weight)
• จำนวนฝาถัง (number of tank lids/hatches)
• น้ำหนักการโหลด (loading weight)

โค้ดประเภทรถและตัวถัง

• 6W / 10W / 18W = รถ 6 ล้อ / 10 ล้อ / 18 ล้อ (RFP p23 row 30, RFP p27 row 16)
• ประเภทตัวถัง (kiosk as-is, SUM p6 screenshot): รถดอก (rigid / single truck) กับ รถพ่วง (trailer) — เป็นตัวเลือก ประเภทรถ ที่เลือกได้

โค้ด Plant / channel / material (จากชีต "Booking Quota Planning" ของ SUM p19 ลงวันที่ 01-Aug-22)

• Plant 2; sub-plant K3 / K4
• Channel BK01–BK09
• โค้ด Tank/bulk BULK21–BULK34
• Material RMX, IDUM, Quick Cast (ความหมายไม่ได้นิยามในต้นทาง)

สินค้า / แบรนด์ที่พบ (SUM p6 kiosk + queue board)

• อินทรีเพชร ปอร์ตแลนด์ประเภท 1 (INSEE Phet / "Petch" Portland Type 1) — ปรากฏในรูปแบบ ถุง (bag), ผง (powder/bulk), และแบบ ถุง 1 ตัน (1-tonne jumbo bag) — ยืนยันการรองรับแบบ multi-SKU ทั้ง bag และ bulk
• master ของสินค้า/แบรนด์ฉบับเต็ม (รวมถึง "INSEE Petch Plus" ของ architect และรายการอื่นๆ) ไม่ได้ระบุไว้ใน extract ที่อ่าน — ตรวจสอบได้เฉพาะตระกูล อินทรีเพชร ปอร์ตแลนด์ประเภท 1 เท่านั้น; รายการ SKU ฉบับสมบูรณ์อยู่ใน master data ต้นทาง [INFERRED — ควรยืนยันกับ data dictionary]

หมายเหตุของผู้วิเคราะห์

• Status = stated: field และ value ของโค้ดมีอยู่ครบ แต่ ความหมายของ value ส่วนใหญ่ยังไม่นิยาม (WeightType 001/002/004/888/999/101; ItemType BB; material RMX/IDUM/Quick Cast; BULK21–34) รายการเหล่านี้ต้องใช้ไฟล์ master-data Excel ฉบับจริง → เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ และคำย่อที่ยังไม่นิยามจะไปต่อยอดที่ อภิธานศัพท์โดเมนและตัวย่อ (Domain glossary & abbreviations)
• ชุดโค้ดเหล่านี้เป็นหัวใจสำคัญต่อ การคำนวณ quota (โมเดล Booking quota อ้างอิงตาม Product / Channel / Loading Type) และต่อ การแยก channel (กฎ "Specify Channel For Booking = Need" และ master ของ truck-ID-per-channel ใน SUM p16) — ดังนั้น dictionary จึงต้องถูกล็อกให้นิ่งก่อนเริ่ม build
• field ของ truck-info ที่แก้ไขได้ต้องเป็นแบบ เลือกจากรายการ ไม่ใช่ free text ("free text input should be avoided", RFP p23 row 30 / RFP p27 row 16) — หมายความว่าทุกชุดตัวเลือกข้างต้นต้องมีอยู่ในรูป master list ที่มีการดูแลรักษา