TLX Vendor Estimation Portal

ยินดีต้อนรับสู่ชุดเอกสาร TLX สำหรับใช้คุยบริษัทพัฒนาซอฟต์แวร์และเปรียบเทียบใบเสนอราคาให้ชัดเจน

วัตถุประสงค์

เอกสารชุดนี้จัดทำจาก requirement หลัก เพื่อ: - ทำความเข้าใจกระบวนการธุรกิจและระบบให้ตรงกัน - แปลง requirement เป็นขอบเขตงานเชิงพัฒนา - ช่วย vendor ประเมินราคา/ระยะเวลาได้แม่นยำขึ้น

เอกสารหลัก

1. Database Schema
2. โครงสร้างข้อมูลหลัก, ความสัมพันธ์, state model, index ที่แนะนำ
3. User Flow Diagram
4. เส้นทางการทำงานของ Seller, Buyer, Admin, Support และ exception flow
5. Software Architecture
6. สถาปัตยกรรมระบบ, data flow, security boundary, deployment baseline
7. Other Documents
8. API contract draft, NFR, integration scope, implementation phases

วิธีใช้งานสำหรับ Vendor

แนะนำให้ vendor อ่านตามลำดับ: - เริ่มที่ User Flow เพื่อเข้าใจภาพธุรกิจ - ตามด้วย Architecture เพื่อเห็นโครงระบบและ integration - ลงรายละเอียดที่ Database Schema และ API/NFR

จากนั้นให้แยก estimate เป็น work package เช่น: - Identity/KYC/RBAC - Product & Registry - Document Lifecycle Engine - Validation/Routing/Callback - Back-office/Monitoring/Audit

สิ่งที่ควรส่งกลับเมื่อเสนอราคา

• Scope ที่ครอบคลุมและไม่ครอบคลุม (In Scope / Out of Scope)
• Effort แยกตาม phase และทีมที่ใช้
• Timeline พร้อม milestone
• ความเสี่ยงและ dependency ที่ต้องได้รับข้อมูลเพิ่ม
• สมมติฐานทางเทคนิคที่กระทบงบประมาณ

เวอร์ชันเอกสาร

• Baseline: v1.0
• Last updated: 2026-04-16

Raw Requirement (ต้นฉบับทั้งหมด)

เนื้อหาด้านล่างคือข้อความจากไฟล์ tlx-business-requirements.txt แบบเต็ม เพื่อให้ผู้อ่านเห็น requirement ต้นฉบับก่อนเข้าดูเอกสารวิเคราะห์

๖.๓.๑ ในการรับส่งและแลกเปลี่ยนข้อมูลทางการค้าและโลจิสติกส์ระหว่างหน่วยงานที่เกี่ยวข้อง
ที่มีความเหมาะสมและสามารถใช้งานได้จริง ส่วนงานความต้องการทางทางธุรกิจ (Business Services
Requirements) ของ ระบบ TLX ต้องรองรับกระบวนการทำงานพื้นฐานทางธุรกิจอย่างน้อย ดังต่อไปนี้
(๑) ระบบทะเบียนและข้อมูลหลัก (Master Data Management)
• รองรับการลงทะเบียนผู้ขาย (Seller) และผู้ซื้อ (Buyer) โดยสามารถบันทึกข้อมูลผู้ที่
เกี่ยวข้องในระบบ TLX ได้ตามความเหมาะสม
• รองรับการนำเข้า (upload) และบริหารจัดการรายการสินค้า (Product Catalog)
รวมถึงรายละเอียดสินค้า เช่น รหัสสินค้า ชื่อสินค้า บาร์โคด ขนาดบรรจุ ลักษณะ
บรรจุหีบห่อ และรูปภาพ
(๒) ระบบบริหารจัดการคำสั่งซื้อ (Order Management)
• รองรับการรับและส่งใบเสนอราคา (Quotation) โดยผู้ขายเริ่มธุรกรรมการเสนอขาย
สินค้าไปยังผู้ซื้อสินค้า
• รองรับการรับและส่งใบสั่งซื้อ (Purchase Order) จากผู้ซื้อสินค้าไปยังผู้ขายสินค้า
โดยข้อมูลราคาต้องเป็นไปตามที่กำหนดในใบเสนอราคา
• รองรับการยืนยันคำสั่งซื้อ (Order Confirmation) จากผู้ขายสินค้าไปยังผู้ซื้อสินค้า
โดยอาจมีการปรับแก้จำนวนสั่งซื้อหรือเงื่อนไขระยะเวลาการส่งสินค้าได้ตาม
สถานการณ์
(๓) ระบบบริหารจัดการการส่งสินค้า (Delivery Management)
• รองรับการรับและส่งใบแจ้งหนี้ (Invoice) หรือใบกำกับภาษี (Tax Invoice) ที่ผู้ขาย
สินค้าออกจากระบบและส่งให้ผู้ซื้อสินค้า เพื่อแจ้งให้ทราบว่ามีการออกเอกสาร
ดังกล่าวแล้ว
• รองรับการรับส่งใบส่งสินค้า (Delivery Note) และการแจ้งเตือนการส่งสินค้า โดยใบ
ส่งสินค้าต้องอ้างอิงใบกำกับภาษี พร้อมข้อมูลการขนส่ง เช่น บริษัทขนส่ง รถขนส่ง
จำนวนบรรจุภัณฑ์ และวันที่คาดว่าจะได้รับสินค้า
• รองรับกระบวนการยืนยันการรับสินค้า (Goods Receipt) โดยผู้ซื้อยืนยันการรับ
สินค้าจากรถขนส่งให้ครบถ้วนตามจำนวนในใบส่งสินค้า และในกรณีที่สินค้าไม่
ครบถ้วนหรือไม่สมบูรณ์ ต้องมีกระบวนการแจ้งเคลมผ่านระบบ
• รองรับกระบวนการที่ผู้ซื้อสามารถยืนยันการได้รับสินค้าครบถ้วนสมบูรณ์ตามรายการ
ในใบแจ้งหนี้ และกำหนดวันนัดชำระเงินผ่านระบบ
(๔) ระบบบริหารจัดการเอกสารทางการเงิน (Invoice & Billing)
• รองรับการรับสารสารส่งใบแจ้งหนี้ (Invoice) หรือใบกำกับภาษี โดยผู้ขายแจ้งข้อมูล
วางบิล ซึ่งประกอบด้วยใบแจ้งหนี้ที่ถึงกำหนดชำระ
• รองรับกระบวนการวางบิลและการยืนยันการชำระเงิน (Payment Confirmation)
โดยผู้ซื้อออกเอกสารยืนยันการชำระเงิน ซึ่งโดยปกติจะเป็นข้อมูลชุดเดียวกับเอกสาร
วางบิล
• รองรับกระบวนการแจ้งการชำระเงินให้ผู้ขาย เมื่อผู้ซื้อชำระเงินแล้ว
๖.๓.๒ ส่วนงานโครงสร้างพื้นฐานและฟังก์ชันสนับสนุนของระบบ (System Infrastructure)
ระบบต้องมีกลไกสนับสนุนการแลกเปลี่ยนข้อมูลที่มีประสิทธิภาพและน่าเชื่อถือ ดังต่อไปนี้
(๑) ช่องทางการเชื่อมต่อใช้งาน (User Interfaces)
• Web Portal พัฒนาหน้าเว็บไซต์สำหรับผู้ประกอบการ ให้สามารถเข้าสู่ระบบเพื่อ
นำเข้าข้อมูลรายการสินค้า (product catalog) และติดตามสถานะธุรกรรม
• Dashboard สำหรับรายงานสถานะและสถิติธุรกรรมที่เกิดขึ้นในระบบ
(๒) Secured API Gateway
• รองรับการเชื่อมต่อผ่าน API (Application Programming Interface) สำหรับ
องค์กรที่มีระบบ ERP เพื่อแลกเปลี่ยนข้อมูลอัตโนมัติ
• มีกลไกการยืนยันตัวตน (Authentication) และมาตรการรักษาความมั่นคงปลอดภัย
ที่เหมาะสม
(๓) Directory Service
• Participant Registry: รายการชื่อผู้เข้าร่วม หรือผู้ใช้งานในระบบ TLX ในส่วนนี้
ผู้ใช้งานสามารถเพิ่มและแก้ไขข้อมูลของผู้ใช้งานได้ตามเหมาะสม สามารถระบุ
ช่องทาง (Endpoint) ที่ใช้ในการรับส่งเอกสารอิเล็กทรอนิกส์ของตน รวมถึงการรับ
และจัดเก็บกุญแจสาธารณะ (Public key) ของผู้ใช้งานในระบบ TLX สำหรับให้คู่ค้า
ทำการเข้ารหัสข้อมูลก่อนส่งผ่านระบบ TLX
Participant Registry จะทำหน้าที่สร้าง participant ID หลังจากที่ผู้เข้าร่วม
ลงทะเบียนสำเร็จแล้ว โดยแบ่งประเภทของผู้ร่วมใน Ecosystem เช่น ผู้ขาย ผู้ซื้อ
หรือเป็นทั้งผู้ขายและผู้ซื้อ และมีฟังก์ชันในการจับคู่คู่ค้า ผู้ใช้งานสามารถร้องขอการ
จับคู่ไปที่คู่ค้า และผู้ที่รับการร้องขอสามารถ ตอบรับ (Accept) หรือ ปฏิเสธ
(Reject) คำร้องในการจับคู่ได้
• Document Registry: รายการชื่อของเอกสารที่ผู้ที่เข้าร่วมในระบบลงทะเบียนไว้ ว่า
สามารถส่ง และรับเอกสารไหน ผ่านช่องทางไหนได้บ้าง
• Product Catalog Registry: รายการข้อมูลของสินค้าโดยแยกตามผู้ขายหรือผู้
ให้บริการในระบบ โดยต้องมีข้อมูลและรายละเอียดสินค้าตามที่ตกลงกับ สพธอ. เช่น
ข้อมูลระบุตัวสินค้า (Identification) รหัสที่ใช้ภายในระบบของผู้ขายเอง, รหัส
บาร์โค้ดมาตรฐาน (GTIN / Barcode): เช่น EAN-13, UPC เพื่อใช้ในการสแกนรับ-
ส่งของ, ชื่อสินค้า, คำอธิบายสินค้า, และหมวดหมู่สินค้า, ข้อมูลทางการค้าและราคา,
ข้อมูลทางกายภาพและบรรจุภัณฑ์ (Physical & Packaging), รูปภาพหรือสื่อข้อมูล
ประกอบ (Media & Metadata) เป็นต้น
• รองรับการค้นหาด้วยคำสำคัญ (Text Search) จากชื่อสินค้า, รายละเอียดสินค้า,
หรือชื่อบริษัท รวมถึงสืบค้นข้อมูลจำเพาะได้ เช่น การค้นหาสินค้าด้วยรหัสบาร์โค้ด9(GTIN), รหัส SKU หรือการค้นหาผู้ประกอบการด้วยเลขประจำตัวผู้เสียภาษี (Tax
ID)
• รองรับการกรองข้อมูล (Faceted Search) ตามคุณสมบัติจำเพาะ เช่น หมวดหมู่
มาตรฐาน (UNSPSC/HS Code), ช่วงราคา, ยี่ห้อ, สถานะสินค้า (Active/Inactive)
และที่ตั้งของผู้ขาย
(๔) Data Orchestration
• ระบบต้องรองรับความสามารถในการกำหนดเส้นทางการส่งข้อมูล (Payload
Routing) โดยพิจารณาเงื่อนไข Metadata เช่น การส่งตามประเภทของเอกสาร
(Document Type), รายชื่อคู่ค้า (Participant ID) หรือสถานะของธุรกรรม โดย
ระบบสามารถตรวจสอบสิทธิ์การสื่อสารระหว่างคู่ค้า ที่กำหนดได้
• รองรับการกำหนดเงื่อนไขการส่งข้อมูลได้หลากหลาย เช่น การส่งตามประเภทของ
เอกสาร (Document Type), การส่งตามรายชื่อคู่ค้า (Participant ID) หรือการส่ง
ตามสถานะของธุรกรรม โดยต้องสามารถกำหนดค่าปลายทาง (Endpoint) ได้ผ่าน
ระบบทะเบียน (Directory Service) หรือการตั้งค่าระบบ
• สามารถแจ้งข้อมูลกลับไปที่ต้นทางหรือระบบ ERP จำลอง ว่าการส่งหรือรับข้อความ
สำเร็จหรือล้มเหลว กรณีที่พบปัญหาจากการส่งหรือรับให้สาเหตุเบื้องต้นที่เกิดจาก
การส่งหรือรับนั้น
(๕) Message Validation
• การตรวจสอบโครงสร้างข้อมูล (Structural Validation) ต้องสามารถตรวจสอบ
โครงสร้างข้อมูลที่รับมาจากระบบ ERP จำลองของผู้เข้าร่วมได้ อาจรองรับการ
ตรวจสอบผ่าน API ของระบบที่ สพธอ. กำหนด หรือระบบอื่นตามที่ได้รับความ
เห็นชอบ
• การตรวจสอบความถูกต้องเชิงความหมาย (Semantic Validation) ในการรับข้อมูล
จากระบบ ERP จำลอง TLX จะได้รับข้อมูลอยู่ในรูปแบบ JWE ดังนั้น ข้อมูลใน JWE
ที่ปรากฏจะต้องระบุข้อมูลต่อไปนี้เป็นอย่างน้อย
Message ID : รหัสอ้างอิงข้อความที่ไม่ซ้ำกัน ใช้สำหรับบันทึกประวัติการส่งลงใน
ระบบบันทึกเหตุการณ์ (Audit Log) และอ้างอิงในกรณที่พบปัญหา
sender_id (Participant ID) เลขระบุตัวตนผู้ส่ง ใช้ตรวจสอบสิทธิ์กับ Participant
Registry ว่าผู้ส่งลงทะเบียนในระบบนิเวศ (Ecosystem)
receiver_id (Participant ID) เลขรหัสระบุตัวตนผู้รับ ใช้ค้นหาปลายทาง
(Endpoint) ในระบบทะเบียนเพื่อทำการ Routingdoc_type (Document Type) ประเภทเอกสาร (เช่น Invoice, PO) ใช้ตรวจสอบ
กับ Document Registry ว่าผู้รับปลายทางสามารถรับเอกสารประเภทนี้ผ่าน
ช่องทางไหนได้บ้าง
timestamp วันและเวลาที่สร้างข้อความ
(๖) Trust Services
• ระบบบันทึกเหตุการณ์ (Audit Log) ระบบต้องจัดให้มีกลไกการบันทึกเหตุการณ์ที่
เกิดขึ้นในระบบอย่างครบถ้วนและสามารถตรวจสอบย้อนหลังได้ โดยต้องบันทึกข้อมูล
อย่างน้อย ได้แก่ รหัสผู้ใช้งาน (User ID หรือ Account) วันและเวลา (Timestamp)
รายละเอียดกิจกรรมที่ผู้ใช้งานดำเนินการ และฟังก์ชันหรือส่วนของระบบที่เกี่ยวข้อง
กับกิจกรรมนั้น เพื่อใช้เป็นหลักฐานในการตรวจสอบและติดตามการใช้งานของระบบ
(๗) Notification
• ระบบต้องจัดให้มีช่องทางการแจ้งเตือนผ่านสื่ออิเล็กทรอนิกส์ที่เหมาะสม เช่น อีเมล
หรือช่องทางอื่นตามที่ระบบรองรับ เพื่อให้ผู้ใช้งานรับทราบเมื่อมีเอกสารหรือธุรกรรม
ที่เกี่ยวข้องเกิดขึ้น ทั้งนี้ ผู้ใช้งานต้องสามารถกำหนดหรือเลือกช่องทางการแจ้งเตือน
ได้จากตัวเลือกที่ระบบจัดเตรียมไว้
๖.๓.๓ ระบบบริหารจัดการสำหรับผู้ดูแลระบบ (Back-office Management System) ผู้รับจ้าง
ต้องพัฒนาระบบส่วนหลังบ้านสำหรับผู้ดูแลระบบ (System Administrator) และเจ้าหน้าที่สนับสนุน (Support
Staff) เพื่อใช้ในการบริหารจัดการ การตั้งค่า และการตรวจสอบการทำงานของระบบ ให้สามารถกำกับดูแลและ
ควบคุมการดำเนินงานของแพลตฟอร์มได้อย่างมีประสิทธิภาพ โดยอย่างน้อยต้องมีฟังก์ชันการทำงานดังต่อไปนี้
(๑) ระบบจัดการผู้ใช้งานและสิทธิ์การเข้าใช้งาน (User & Access Management)
• รองรับกระบวนการตรวจสอบและอนุมัติการลงทะเบียนของผู้ประกอบการ
(KYC/KYB) โดยเจ้าหน้าที่สามารถเรียกดูเอกสารแนบ ดำเนินการอนุมัติ (Approve)
หรือปฏิเสธ (Reject) พร้อมระบุเหตุผลประกอบการพิจารณาได้
• รองรับการกำหนดสิทธิ์การเข้าใช้งานในรูปแบบ Role-based Access Control โดย
สามารถกำหนดบทบาท (Role) และสิทธิ์การเข้าถึง (Permission) ได้อย่างยืดหยุ่น
เช่น สิทธิ์ผู้ดูแลระบบระดับสูง (Admin) สิทธิ์เจ้าหน้าที่สนับสนุน (Support) หรือสิทธิ์
ผู้ใช้งาน (User) เป็นต้น
(๒) ระบบจัดการข้อมูลหลักและการตั้งค่าระบบ (Master Data & Configuration)
• รองรับการบริหารจัดการโครงสร้างข้อมูล (Message Schema) และรายการ
รหัสมาตรฐาน (Code List Management) โดยเจ้าหน้าที่สามารถเพิ่ม ลบ หรือแก้ไข
รหัสมาตรฐาน (Standard Codes) และเทมเพลตของโครงสร้างข้อมูลในระบบผ่าน
หน้าจอการตั้งค่าของระบบได้ เช่น รหัสหน่วยนับ รหัสสกุลเงิน และรหัสประเภท
เอกสาร โดยไม่จำเป็นต้องแก้ไขที่ Source Code หรือปรับปรุงโปรแกรมโดยตรง11
(๓) ระบบติดตามและตรวจสอบธุรกรรม (Transaction Monitoring & Support)
• รองรับฟังก์ชันแสดงรายละเอียดธุรกรรม (Transaction Viewer) โดยเจ้าหน้าที่
สามารถค้นหาและเรียกดูข้อมูลธุรกรรม (Transaction Detail) ที่เกิดขึ้นในระบบได้
เพื่อใช้ในการตรวจสอบและแก้ไขปัญหาให้ผู้ใช้งาน (Troubleshooting)
(๔) ระบบตรวจสอบประวัติการใช้งาน (Security Audit Log)
• รองรับการเรียกดูประวัติการใช้งาน (Audit Log) ของทั้งผู้ใช้งานทั่วไปและเจ้าหน้าที่
ผู้ดูแลระบบ โดยแสดงข้อมูลว่าใครดำเนินการใด เมื่อใด (Who, What, When) และ
สามารถกรองข้อมูลตามช่วงเวลา หรือชื่อผู้ใช้งานได้ เพื่อให้สามารถตรวจสอบ
ย้อนหลังได้อย่างโปร่งใส
(๕) แดชบอร์ดสรุปภาพรวมระบบ (System Dashboard)
• แสดงภาพรวมสถานะของระบบ (System Health) ปริมาณธุรกรรมที่เกิดขึ้นรายวัน
หรือรายเดือน และจำนวนผู้ใช้งานที่ลงทะเบียนใหม่ เพื่อสนับสนุนการติดตามและ
ประเมินผลการดำเนินงานของระบบในภาพรวม