docs(sdlc): reformat work products to audited reference layout
This commit is contained in:
Thanakorn
+112
@@ -0,0 +1,112 @@
|
||||
# Software Requirements
|
||||
|
||||
<!-- footer: SRS -->
|
||||
|
||||
| Document No | Software Requirements | Release, Version, By: | 25690225 V1.0 NoC |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารบันทึกและสรุปความต้องการซอฟต์แวร์ (Software Requirements Specification) |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objectives)
|
||||
|
||||
เพื่อแปลงความต้องการของลูกค้าที่ได้รับอนุมัติแล้วให้เป็นความต้องการเชิงเทคนิคของซอฟต์แวร์ ครอบคลุมมาตรฐาน โครงสร้าง ส่วนประกอบ ความสัมพันธ์ ประสิทธิภาพ ส่วนเชื่อมต่อ ความปลอดภัย ฐานข้อมูล และการจัดการข้อผิดพลาด เพื่อใช้เป็นเอกสารอ้างอิงหลักในการออกแบบระบบ พัฒนา และทดสอบ
|
||||
|
||||
## ผู้มีส่วนได้ส่วนเสีย (Stakeholders)
|
||||
|
||||
| ลำดับ | ชื่อ | หน่วยงาน/ตำแหน่ง | บทบาท |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | คุณเสรี วิริยะสกุลธรณ์ | ผู้บริหาร (CEO) | Project Sponsor อนุมัติความต้องการ |
|
||||
| 2 | คุณอภิรัชช์ สุภัทรประทีป | ผู้จัดการโครงการ | บริหารจัดการโครงการ |
|
||||
| 3 | คุณนพพงษ์ เจริญสุข | นักวิเคราะห์ระบบ | จัดทำและควบคุมความต้องการซอฟต์แวร์ |
|
||||
| 4 | คุณธนกร สถิตวิทยากุล | นักพัฒนาระบบ | พัฒนาระบบตามความต้องการ |
|
||||
| 5 | คุณปริญ งามขำ | ผู้ทดสอบระบบ | จัดทำ Test Case จากความต้องการ |
|
||||
|
||||
## ความต้องการซอฟต์แวร์ (Software Requirements)
|
||||
|
||||
| ID | Topic | Result* | Remark |
|
||||
| --- | --- | :---: | --- |
|
||||
| SR01: Standards of Software | | | |
|
||||
| SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | A | CR12:004, CR14:001–CR14:003, CR09:003, CR10:004, CR11:001–CR11:004 |
|
||||
| SR01:002 | ระบบต้องใช้เทคโนโลยี PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js (Socket.IO, pm2) | A | CR04:004, CR12:001 |
|
||||
| SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | A | CR07:001, CR10:001, CR10:002, CR08:001, CR08:002, CR13:003 |
|
||||
| SR01:004 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt (PASSWORD_BCRYPT) และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | A | CR12:003 |
|
||||
| SR01:005 | ค่าตั้งค่าและความลับ (app/config.php, .env) ต้องถูกยกเว้นจาก Source Control และสร้างขึ้นตอนติดตั้ง | A | CR06:002, CR09:002, CR10:003 |
|
||||
| SR01:006 | แอปพลิเคชันและงานตามกำหนดเวลาต้องใช้เขตเวลา Asia/Bangkok | A | CR07:002 |
|
||||
| SR02: Software Structure Considerations | | | |
|
||||
| SR02:001 | ระบบต้องเป็น Web-based Application แบบหลายหน้า (Multi-page PHP) | A | CR04:001 |
|
||||
| SR02:002 | ส่วนติดต่อผู้ใช้ต้องเป็น Responsive Design รองรับ Desktop / Tablet / Mobile | A | CR05:001, CR07:003 |
|
||||
| SR02:003 | ตรรกะทางธุรกิจต้องจัดเป็น Manager/Service Classes ที่เรียกใช้จาก Page Controller แยกจากส่วนแสดงผล | A | CR09:001 |
|
||||
| SR02:004 | การเข้าถึงข้อมูลต้องผ่าน Manager Classes ไม่กระจาย SQL ในหน้าเพจ | A | CR09:001 |
|
||||
| SR02:005 | ระบบต้องติดตั้งเป็น Container Stack ผ่าน Docker Compose ได้ นอกเหนือจากการติดตั้งแบบ Manual | A | CR10:002 |
|
||||
| SR03: Software Elements | | | |
|
||||
| SR03:001 | โมดูลผู้ใช้งานและสิทธิ์: ลงทะเบียน, Onboarding, เข้าสู่ระบบ, บทบาท Owner/Admin/Staff/Viewer, สิทธิ์แอปพลิเคชัน (app/login/, UserManager, PasswordManager, PasswordResetManager) | A | CR01:001–CR01:004 |
|
||||
| SR03:002 | โมดูลตั้งค่าบริษัท: ข้อมูลบริษัท, SMTP, การตั้งค่าระบบ (app/setting/, CompanyProfileManager, CompanySettingManager, SmtpManager) | A | CR01:004, CR03:005 |
|
||||
| SR03:003 | โมดูลข้อมูลหลัก: คลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ผู้ติดต่อ (app/inventory/, app/contact/, WarehouseManager, ProductManager, ContactManager) | A | CR01:005, CR01:006 |
|
||||
| SR03:004 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) | A | CR01:007–CR01:012, CR01:019, CR05:005 |
|
||||
| SR03:005 | โมดูลขาย: ใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน/ใบลดหนี้ (app/order/, app/revenue/, QuotationManager, OrderManager, InvoiceManager, ReturnManager) | A | CR01:013 |
|
||||
| SR03:006 | โมดูลจัดซื้อ: ใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ, ใบคืนสินค้าผู้ขาย (app/po/, PurchaseRequestManager, PurchaseOrderManager, SupplierReturnManager) | A | CR01:014 |
|
||||
| SR03:007 | โมดูลการเงิน: ใบวางบิลรับ, ใบเสร็จ, ใบวางบิลจ่าย, ใบสำคัญจ่าย (app/finance/, ReceiptBillingManager, ReceiptManager, PaymentBillingManager, PaymentManager) | A | CR01:015 |
|
||||
| SR03:008 | โมดูลบัญชี: ผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน, บัญชีแยกประเภท (app/accounting/, app/journal/, PostingManager) | A | CR01:016 |
|
||||
| SR03:009 | โมดูลรายงานและแดชบอร์ด: รายงานสต๊อก, รายงานการเงิน, แดชบอร์ด (app/reports/, app/dashboard/, app/ac_dashboard/, ReportManager, EtlStockManager) | A | CR01:011, CR01:017, CR01:020 |
|
||||
| SR03:010 | โมดูลควบคุมเอกสาร: ออกเลขที่เอกสาร, วงจรชีวิต/สถานะ, ประวัติรายการ (DocumentNumberManager, BatchActionManager) | A | CR01:018, CR01:023 |
|
||||
| SR03:011 | บริการแจ้งเตือนและงานตามกำหนดเวลา: Socket.IO และ Scheduler (nodejs/server.js, nodejs/scheduler.js, app/cron/) | A | CR01:021, CR01:022 |
|
||||
| SR04: Software Elements Relationship | | | |
|
||||
| SR04:001 | ทุกโมดูลปฏิบัติการต้องเข้าถึงได้ผ่านการยืนยันตัวตนและการตรวจสิทธิ์ของโมดูลผู้ใช้งานเท่านั้น | A | CR01:002, CR01:024, CR04:003, CR05:002 |
|
||||
| SR04:002 | โมดูลขาย จัดซื้อ และการเงิน ต้องบันทึกผลกระทบต่อสต๊อกและ GL ผ่านโมดูลคลังสินค้าและบัญชี ไม่ทำซ้ำตรรกะ | A | CR01:013–CR01:016 |
|
||||
| SR04:003 | โมดูลรายงานต้องอ่านข้อมูลภายใต้ขอบเขตบริษัท/คลังที่โมดูลข้อมูลหลักและคลังสินค้าบังคับใช้ | A | CR01:024, CR08:004 |
|
||||
| SR04:004 | บริการ Node.js ต้องรับเหตุการณ์จากแอปพลิเคชัน PHP ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret เท่านั้น | A | CR01:021, CR03:003 |
|
||||
| SR04:005 | ทุกโมดูลที่สร้างเอกสารธุรกิจต้องเรียกใช้โมดูลควบคุมเอกสารเพื่อออกเลขที่เอกสาร | A | CR01:018 |
|
||||
| SR05: Performance Characteristics | | | |
|
||||
| SR05:001 | งานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ต้องเสร็จภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | A | CR02:001 |
|
||||
| SR05:002 | ยอดสรุปสต๊อก/GL/แดชบอร์ดต้องคำนวณล่วงหน้าตามกำหนดเวลา (etl_stock_summary, etl_gl_summary) | A | CR02:002, CR01:022, CR08:005 |
|
||||
| SR05:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันตามที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | A | CR02:003 |
|
||||
| SR05:004 | ระบบต้องมี Health Check ทุก 5 นาที และแจ้งเตือนผู้ดูแลเมื่อล้มเหลวติดต่อกัน 2 ครั้ง | A | CR08:003 |
|
||||
| SR06: Software Interfaces | | | |
|
||||
| SR06:001 | แอปพลิเคชัน PHP ต้องเชื่อมต่อฐานข้อมูล MariaDB 2 ฐาน: wms (ผู้ใช้/บริษัท) และ wms2 (คลัง/บัญชี) | A | CR03:001 |
|
||||
| SR06:002 | ระบบต้องใช้งานได้บน Chrome, Edge และ Firefox รุ่นปัจจุบัน | A | CR03:002 |
|
||||
| SR06:003 | ระบบต้องรองรับ Mobile/Tablet Browser ผ่าน Responsive UI | A | CR07:003 |
|
||||
| SR06:004 | แอปพลิเคชัน PHP ต้องส่งเหตุการณ์ไป Node.js ผ่าน HTTP Endpoint ภายใน (NODE_EMIT_URL + NODE_EMIT_SECRET) และส่งอีเมลผ่าน SMTP ต่อบริษัท | A | CR03:003, CR03:005 |
|
||||
| SR06:005 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint (NODE_PUBLIC_URL) เพื่อรับการแจ้งเตือน | A | CR03:004 |
|
||||
| SR07: Security Characteristics | | | |
|
||||
| SR07:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องผ่าน HTTPS/TLS | A | CR06:001 |
|
||||
| SR07:002 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | A | CR06:003, CR14:004 |
|
||||
| SR07:003 | ระบบต้องอนุญาต Session ที่ใช้งานอยู่เพียงหนึ่งต่อบัญชี (บล็อก Concurrent Login) | A | CR06:006 |
|
||||
| SR07:004 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting ทั้งด้านรับข้อมูลและแสดงผล | A | CR06:005 |
|
||||
| SR07:005 | RBAC (Owner/Admin/Staff/Viewer) ต้องบังคับใช้ที่ฝั่งเซิร์ฟเวอร์ ไม่ใช่เพียงการซ่อนเมนู | A | CR06:004 |
|
||||
| SR08: Database Design Requirements | | | |
|
||||
| SR08:001 | ฐานข้อมูล wms: user, company_list, company_map_user, company_setting, company_smtp, company_usage, whitelist | A | CR01:001–CR01:004, CR04:002 |
|
||||
| SR08:002 | ตารางข้อมูลหลัก (wms2): md_warehouse, md_storage, md_bin, md_product, md_product_category, md_contact, md_contact_type, md_account, md_account_formula, md_account_formula_item, md_department, md_barcode, md_sku_barcode_label, md_lot, md_lock_operation | A | CR01:005, CR01:010, CR01:016 |
|
||||
| SR08:003 | ตารางรายการ (td_*): td_stock, td_order/_item, td_quotation/_item, td_invoice/_item, td_return/_item, td_purchase_request/_item, td_purchase_order/_item, td_supplier_return/_item, td_receipt/_item, td_receipt_billing/_item, td_payment/_item, td_payment_billing/_item, td_gl/td_gl_item, td_batch_action, td_bin_log | A | CR01:007–CR01:018 |
|
||||
| SR08:004 | ตารางสรุปยอดและควบคุมเอกสาร: etl_stock_summary, etl_gl_summary, document_number_sequences, document_types, schema_migrations | A | CR01:018, CR01:022, CR09:004 |
|
||||
| SR08:005 | ตารางทั้งหมดต้องสร้างซ้ำได้ในสภาพแวดล้อมใหม่ผ่าน setup.php โดยไม่ต้องแก้ Schema ด้วยมือ | A | CR10:001, CR09:004 |
|
||||
| SR09: Error Handling and Recovery Attributes | | | |
|
||||
| SR09:001 | การลบ ยกเลิก หรือ Void เอกสารควบคุมต้องมี Confirm Dialog | A | CR05:004, CR01:023 |
|
||||
| SR09:002 | ข้อผิดพลาดต้องแสดงข้อความที่ผู้ใช้เข้าใจได้แทน Fatal Error | A | CR05:003, CR13:004 |
|
||||
| SR09:003 | การเปลี่ยนแปลงที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction และป้องกันยอดติดลบ/ซ้ำ | A | CR13:001, CR13:002, CR01:008 |
|
||||
|
||||
## Remark
|
||||
|
||||
- \* Result : A = Accepted, U = Unaccepted, N/A = Not Applicable
|
||||
- ช่อง Remark แสดงรหัสความต้องการของลูกค้า (Customer Requirements) ที่เป็นที่มาของความต้องการซอฟต์แวร์แต่ละรายการ
|
||||
- ความต้องการซอฟต์แวร์ที่ไม่มีที่มาจากความต้องการของลูกค้าต้องผ่าน Change Report ก่อนถือเป็นข้อผูกพัน
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-144
@@ -1,144 +0,0 @@
|
||||
# Software Requirements Specification (SRS)
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Requirements Specification |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Software Requirements Recording and Summary Document (Software Requirements Specification) |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Recorder | Thanakorn Sathitwitayakul — Developer |
|
||||
| Status | Final — reformulates the approved Customer Requirements into technical software requirements |
|
||||
|
||||
## Objective
|
||||
|
||||
To restate the approved Customer Requirements as technical software requirements — standards, structure, elements, relationships, performance, interfaces, security, database, and error handling — so they can drive Software Design, Software Components, Test Cases, and Traceability.
|
||||
|
||||
## Basis and scaling note
|
||||
|
||||
The example reference package (`200-TAS-25-001-00`) enumerates one SR row per screen/CRUD action because that project is a small brochure site with ~6 modules. BRN WMS is a multi-domain warehouse/ERP system with 31 backend manager/service classes plus one shared trait (32 files) and 17 top-level application areas (Section 3 below). Reproducing CRUD-button-level granularity would create hundreds of near-duplicate rows without adding traceability value. This SRS therefore keeps the same category structure (SR01–SR09) as the example but sets granularity at the same level already approved in the Customer Requirements (FR-001–FR-024, NFR-001–NFR-010), one SR row per requirement or tight requirement group. Every SR row's Remark links back to its Customer Requirements ID.
|
||||
|
||||
## SR01: Standards of Software
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR01:001 | The system shall be developed in alignment with ISO/IEC 29110 Basic Profile documentation and traceability practice. | A | NFR-009 |
|
||||
| SR01:002 | The system shall use PHP 8+ for the application layer, MySQL/MariaDB for data storage, and Node.js for real-time/scheduled services. | A | NFR-008 |
|
||||
| SR01:003 | The system shall be deployable on a Linux server, either via manual LAMP-style installation (`setup.php`) or the provided Docker Compose stack (php-apache, mariadb, node/pm2). | A | NFR-004 |
|
||||
| SR01:004 | User passwords shall be hashed with `PASSWORD_BCRYPT` (PHP default cost factor); plaintext passwords shall never be stored or logged. | A | NFR-002 |
|
||||
| SR01:005 | Configuration secrets (`app/config.php`, `.env`) shall be excluded from source control and generated at deployment time. | A | NFR-001 |
|
||||
|
||||
## SR02: Software Structure Considerations
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR02:001 | The system shall be a browser-based, multi-page PHP web application (not a single native client). | A | FR-002, operational context |
|
||||
| SR02:002 | The user interface shall be responsive across desktop and warehouse-floor (tablet/mobile) viewports. | A | NFR-005 |
|
||||
| SR02:003 | Application logic shall be organized as PHP manager/service classes invoked by page controllers, separated from page presentation. | A | NFR-007 |
|
||||
| SR02:004 | Data access shall be encapsulated through manager classes rather than inline SQL scattered across pages, where practical. | A | NFR-007 |
|
||||
| SR02:005 | The system shall be deployable as a container stack (Docker Compose: php-apache, mariadb, node/pm2) in addition to manual installation. | A | NFR-004 |
|
||||
|
||||
## SR03: Software Elements (Modules)
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR03:001 | Identity/access module: registration, onboarding, authentication, role (Owner/Admin/Staff/Viewer) and application-access management (`app/login/`, `UserManager`, `PasswordManager`, `PasswordResetManager`). | A | FR-001–FR-004 |
|
||||
| SR03:002 | Company/system configuration module: company profile, SMTP, system settings (`app/setting/`, `CompanyProfileManager`, `CompanySettingManager`, `SmtpManager`). | A | FR-004 |
|
||||
| SR03:003 | Master data module: warehouses, storage/bins, product categories, products, contacts (`app/inventory/`, `app/contact/`, `WarehouseManager`, `ProductManager`, `ContactManager`). | A | FR-005, FR-006 |
|
||||
| SR03:004 | Inventory/warehouse operations module: stock-in, stock-out, transfer, lot/serial/expiry, barcode labels (`app/ics/`, `StockManager`, `StockSourceManager`, `BarcodeManager`). | A | FR-007–FR-012 |
|
||||
| SR03:005 | Sales module: quotation, order, invoice, return, credit note (`app/order/`, `app/revenue/`, `QuotationManager`, `OrderManager`, `InvoiceManager`, `ReturnManager`). | A | FR-013 |
|
||||
| SR03:006 | Purchasing module: purchase request, purchase order, purchase invoice, supplier return (`app/po/`, `PurchaseRequestManager`, `PurchaseOrderManager`, `SupplierReturnManager`). | A | FR-014 |
|
||||
| SR03:007 | Finance module: receipt billing, receipts, payment billing, payments (`app/finance/`, `ReceiptBillingManager`, `ReceiptManager`, `PaymentBillingManager`, `PaymentManager`). | A | FR-015 |
|
||||
| SR03:008 | Accounting module: chart of accounts, departments, account formulas, journals, general ledger (`app/accounting/`, `app/journal/`, `PostingManager`). | A | FR-016 |
|
||||
| SR03:009 | Reporting/dashboard module: stock, financial, and operational reports and dashboards (`app/reports/`, `app/dashboard/`, `app/ac_dashboard/`, `app/revenue/`, `app/expense/`, `ReportManager`). | A | FR-011, FR-017, FR-020 |
|
||||
| SR03:010 | Document-control module: controlled document numbering and lifecycle/status (`DocumentNumberManager`). | A | FR-018 |
|
||||
| SR03:011 | Notification/scheduler services: Socket.IO notifications and scheduled aggregate/alert jobs (`nodejs/server.js`, `nodejs/scheduler.js`, `app/cron/`, `EtlStockManager`). | A | FR-021, FR-022 |
|
||||
|
||||
## SR04: Software Elements Relationship
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR04:001 | Every operational module shall be reachable only through the identity/access module's authentication and role/application-access checks. | A | FR-002, FR-024 |
|
||||
| SR04:002 | Sales, purchasing, and finance modules shall post related stock and general-ledger effects through the inventory and accounting modules rather than duplicating their logic. | A | FR-013–FR-016 |
|
||||
| SR04:003 | The reporting module shall read from, and never bypass, the authorization scope enforced by the master-data and inventory modules (company/warehouse isolation). | A | FR-024 |
|
||||
| SR04:004 | The notification/scheduler services shall relay events from the PHP application through a secret-protected internal endpoint, not directly from the browser to internal services. | A | NFR-002 |
|
||||
| SR04:005 | Document-control numbering shall be invoked by every module that creates a controlled business document (order, invoice, receipt, payment, journal, etc.). | A | FR-018 |
|
||||
|
||||
## SR05: Performance Characteristics
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR05:001 | Representative daily operations (screen loads, list/search, document creation) shall complete within practical operational time on the agreed environment. | A | NFR-006 |
|
||||
| SR05:002 | Stock, GL, and dashboard aggregates shall be maintained on a schedule (ETL/summary tables) so dashboard and report queries do not require full recomputation on each request. | A | NFR-006, FR-022 |
|
||||
| SR05:003 | The system shall support the representative concurrent-user and data-volume levels agreed for the production environment. | A | NFR-006 |
|
||||
|
||||
## SR06: Software Interfaces
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR06:001 | The PHP application shall connect to two MariaDB databases: `wms` (identity/company) and `wms2` (WMS/accounting). | A | Operational context, SR08 |
|
||||
| SR06:002 | The application shall be usable on current standards-based browsers (Chrome, Edge, Firefox). | A | NFR-008 |
|
||||
| SR06:003 | The application shall support mobile/tablet browser access through the responsive UI. | A | NFR-005 |
|
||||
| SR06:004 | The PHP application shall relay events to the Node.js service over an internal, secret-protected HTTP endpoint (`NODE_EMIT_URL`, `NODE_EMIT_SECRET`). | A | NFR-002 |
|
||||
| SR06:005 | The browser shall connect to the Node.js Socket.IO endpoint (`NODE_PUBLIC_URL`) for real-time notification delivery. | A | FR-021 |
|
||||
|
||||
## SR07: Security Characteristics
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR07:001 | Production deployment shall terminate the client connection over HTTPS/TLS. | A | NFR-001 |
|
||||
| SR07:002 | Server-side actions shall validate input and enforce authentication, authorization, and tenant (company/warehouse) scope. | A | NFR-002 |
|
||||
| SR07:003 | The system shall enforce single active-session (block concurrent login) behavior per the implemented login policy. | A | NFR-002 |
|
||||
| SR07:004 | The system shall protect against SQL injection and cross-site scripting in server-side input handling and output rendering. | A | NFR-002 |
|
||||
| SR07:005 | Role-based access control (Owner/Admin/Staff/Viewer) shall restrict server-side actions, not only UI visibility. | A | FR-002, NFR-002 |
|
||||
|
||||
## SR08: Database Design Requirements
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR08:001 | Identity/company database (`wms`): `user`, `company_list`, `company_map_user`, `company_setting`, `company_smtp`, `company_usage`, `whitelist`. | A | FR-001–FR-004 |
|
||||
| SR08:002 | Master-data tables in the WMS database (`wms2`): `md_warehouse`, `md_storage`, `md_bin`, `md_product`, `md_product_category`, `md_contact`, `md_contact_type`, `md_account`, `md_account_formula`, `md_account_formula_item`, `md_department`, `md_barcode`, `md_sku_barcode_label`, `md_lot`, `md_lock_operation`. | A | FR-005, FR-006, FR-010, FR-012, FR-016 |
|
||||
| SR08:003 | Transaction-data tables (`td_*`): `td_stock`, `td_order`/`td_order_item`, `td_quotation`/`_item`, `td_invoice`/`_item`, `td_return`/`_item`, `td_purchase_request`/`_item`, `td_purchase_order`/`_item`, `td_supplier_return`/`_item`, `td_receipt`/`_item`, `td_receipt_billing`/`_item`, `td_payment`/`_item`, `td_payment_billing`/`_item`, `td_gl`/`td_gl_item`, `td_batch_action`, `td_bin_log`. | A | FR-007–FR-018 |
|
||||
| SR08:004 | Aggregate/document-control tables: `etl_stock_summary`, `etl_gl_summary`, `document_number_sequences`, `document_types`, `schema_migrations`. | A | FR-018, FR-022 |
|
||||
| SR08:005 | All tables created by the delivered `setup.php` shall be reproducible in a fresh environment without manual schema editing. | A | NFR-004 |
|
||||
|
||||
## SR09: Error Handling and Recovery Attributes
|
||||
|
||||
| ID | Requirement | Result* | Remark |
|
||||
|---|---|---|---|
|
||||
| SR09:001 | Destructive actions (delete, void, cancel of a controlled record) shall require an explicit confirmation step. | A | Usability practice; not a numbered CR/FR but implemented consistently across modules |
|
||||
| SR09:002 | Errors shall present a usable message to the user rather than an unhandled fatal error, for the primary operational workflows. | A | NFR-006 |
|
||||
| SR09:003 | Related database changes (e.g., document + stock + GL postings) shall be transactional where required to avoid partial/inconsistent updates. | A | NFR-003 |
|
||||
|
||||
Remark:
|
||||
|
||||
- \* Result: A = Accepted (implemented and evidenced in the current codebase), U = Unaccepted, N/A = Not Applicable. No SR row in this document is marked A without an identifiable implementing module, class, or table.
|
||||
- This SRS restates already-approved Customer Requirements; it does not introduce new scope. Any SR row without a direct FR/NFR precedent must be raised through the Change Report before being treated as binding.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+168
@@ -0,0 +1,168 @@
|
||||
# Software Design
|
||||
|
||||
<!-- footer: SD -->
|
||||
|
||||
| Document No | Software Design | Release, Version, By: | 25690306 V1.0 NoC |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารการออกแบบระบบ (System Design Document) |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## HIGH LEVEL DESIGN
|
||||
|
||||
### Use Case Diagram
|
||||
|
||||
ผู้ใช้งานของระบบและกลุ่มการใช้งานหลัก
|
||||
|
||||
| Actor | คำอธิบาย | การใช้งานหลัก |
|
||||
| --- | --- | --- |
|
||||
| Owner | เจ้าของบริษัท สิทธิ์สูงสุดภายในบริษัท | ตั้งค่าบริษัท จัดการผู้ใช้ และใช้งานทุกโมดูล |
|
||||
| Admin | ผู้ดูแลระบบภายในบริษัท | จัดการข้อมูลหลัก ผู้ใช้ สิทธิ์ และใช้งานทุกโมดูลปฏิบัติการ |
|
||||
| Staff | ผู้ปฏิบัติงาน | บันทึกรายการคลังสินค้า ขาย จัดซื้อ และการเงินตามสิทธิ์ |
|
||||
| Viewer | ผู้ใช้แบบอ่านอย่างเดียว | ดูหน้าจอและรายงานที่ได้รับสิทธิ์ |
|
||||
| System Scheduler | ผู้กระทำอัตโนมัติ (Node.js) | สรุปยอดสต๊อก/GL และแจ้งเตือนตามกำหนดเวลา |
|
||||
| SMTP Service | ผู้กระทำภายนอก | ส่งอีเมล Onboarding กู้คืนรหัสผ่าน และแจ้งเตือน |
|
||||
|
||||
### Component Diagram
|
||||
|
||||
โครงสร้างส่วนประกอบของระบบแบ่งตามชั้นการทำงาน
|
||||
|
||||
| ชั้น (Layer) | ส่วนประกอบ | อ้างอิง SR |
|
||||
| --- | --- | --- |
|
||||
| Presentation | หน้าจอ PHP ในแต่ละโมดูล (`app/<module>/`), JavaScript และ CSS ที่รองรับ Responsive | SR02:002, SR06:002, SR06:003 |
|
||||
| Business Logic | Manager/Service Classes ใน `app/assets/utils/classes/` เรียกใช้จาก Page Controller | SR02:003, SR03:001–SR03:011 |
|
||||
| Data Access | Manager Classes เข้าถึงฐานข้อมูล MariaDB โดยตรง พร้อม Trait รวมตรรกะที่ใช้ร่วมกัน | SR02:004, SR06:001, SR08:001–SR08:005 |
|
||||
| Real-time / Scheduler | บริการ Node.js (`server.js`, `scheduler.js`) ควบคุมด้วย pm2 | SR03:011, SR06:004, SR06:005 |
|
||||
| External | บริการ SMTP สำหรับส่งอีเมล และ Socket.IO Client บน Browser | SR06:004, SR06:005 |
|
||||
|
||||
### Deployment Diagram
|
||||
|
||||
การติดตั้งระบบแบ่งเป็น 4 ชั้นบริการ
|
||||
|
||||
| ชั้นการติดตั้ง (Tier) | ส่วนประกอบ | อ้างอิง SR |
|
||||
| --- | --- | --- |
|
||||
| Client | Web Browser (Chrome/Edge/Firefox) บน Desktop, Tablet และ Mobile พร้อม Socket.IO Client | SR06:002, SR06:003, SR06:005 |
|
||||
| Web Tier | PHP 8 บน Apache ติดตั้งแบบ Manual หรือ Container `docker/php` | SR01:003, SR02:005 |
|
||||
| Data Tier | MariaDB ฐานข้อมูล `wms` (ผู้ใช้/บริษัท) และ `wms2` (คลัง/บัญชี) | SR06:001, SR08:001–SR08:004 |
|
||||
| Service Tier | Node.js `server.js` และ `scheduler.js` ควบคุมด้วย pm2 | SR03:011, SR06:004 |
|
||||
|
||||
### User Interface Design
|
||||
|
||||
ผังหน้าจอหลักของระบบแบ่งตามโมดูลการใช้งาน
|
||||
|
||||
| กลุ่มหน้าจอ | หน้าจอ |
|
||||
| --- | --- |
|
||||
| Login & Onboarding | เข้าสู่ระบบ / ลงทะเบียนบริษัท / รับคำเชิญเข้าร่วมบริษัท / ลืมรหัสผ่าน / ยืนยัน OTP |
|
||||
| Dashboard | แดชบอร์ดคลังสินค้า / แดชบอร์ดบัญชีและการเงิน |
|
||||
| Master Data | คลังสินค้า / พื้นที่จัดเก็บ / ช่องจัดเก็บ / หมวดสินค้า / สินค้า / ประเภทผู้ติดต่อ / ผู้ติดต่อ |
|
||||
| Inventory Control | รับสินค้าเข้า / จ่ายสินค้าออก / โอนย้ายสินค้า / ยอดคงเหลือ / Lot & Serial / พิมพ์บาร์โค้ด |
|
||||
| Sales | ใบเสนอราคา / ใบสั่งขาย / ใบแจ้งหนี้ / ใบรับคืนและใบลดหนี้ |
|
||||
| Purchasing | ใบขอซื้อ / ใบสั่งซื้อ / ใบแจ้งหนี้ซื้อ / ใบคืนสินค้าผู้ขาย |
|
||||
| Finance | ใบวางบิลรับ / ใบเสร็จรับเงิน / ใบวางบิลจ่าย / ใบสำคัญจ่าย |
|
||||
| Accounting | ผังบัญชี / แผนก / สูตรบัญชี / สมุดรายวัน / บัญชีแยกประเภท |
|
||||
| Reports | รายงานสต๊อก / ความเคลื่อนไหว / ความจุคลัง / สินค้าใกล้หมด / สินค้าหมดอายุ / รายงานการเงิน |
|
||||
| Settings | ข้อมูลบริษัท / SMTP / ผู้ใช้งานและสิทธิ์ / การตั้งค่าระบบ |
|
||||
|
||||
## Software Baseline
|
||||
|
||||
หัวข้อนี้ระบุสิ่งที่ถูกกำหนดเป็น Baseline ของซอฟต์แวร์ วันที่กำหนด และผู้อนุมัติ เพื่อให้ตรวจสอบเส้นทาง Baseline → Configuration → Change ได้ในเอกสารชุดเดียวกัน
|
||||
|
||||
| รายการที่กำหนดเป็น Baseline | ค่าที่ควบคุม | ที่จัดเก็บ |
|
||||
| --- | --- | --- |
|
||||
| Source Code ของแอปพลิเคชัน | Git commit `6c39700` บน branch `main` | Repository หลัก `git@188.166.228.62:nok/wms-app.git` |
|
||||
| โครงสร้างฐานข้อมูล | Schema ที่สร้างโดย `setup.php` และ `docker/mariadb/init-wms2.sql` | ควบคุมใน Repository เดียวกัน |
|
||||
| ค่าตั้งค่าและชุดติดตั้ง | `docker-compose.yml`, `docker/`, `.env.example` (ไม่รวมค่าความลับ) | ควบคุมใน Repository เดียวกัน |
|
||||
| เอกสาร Work Products | Branch `sdlc` และ Tag `sdlc-v1.0-final` | Repository หลักและ Remote สำรอง `git@github.com:thanakorninbox-dev/wms-app.git` |
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| วันที่กำหนด Baseline | 17 สิงหาคม 2569 (Baseline ของระบบที่ส่งมอบ) |
|
||||
| ผู้จัดทำ Baseline | คุณธนกร สถิตวิทยากุล (Developer) |
|
||||
| ผู้ตรวจสอบ | คุณนพพงษ์ เจริญสุข (System Analyst) และ คุณปริญ งามขำ (QA/Tester) |
|
||||
| ผู้อนุมัติ | คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor) พร้อมการตรวจรับเมื่อ 17 สิงหาคม 2569 |
|
||||
| เอกสารควบคุมที่เกี่ยวข้อง | Software Configuration (WP 8) ระบุรายการ Configuration Item และการควบคุมเวอร์ชัน |
|
||||
| การสอบกลับ | Traceability Record (WP 13) เชื่อมโยงความต้องการกับ Software Unit และ Test Case บน Baseline นี้ |
|
||||
| การเปลี่ยนแปลง Baseline | ต้องผ่าน Change Report (CH-001–CH-003) และบันทึกผลใน Correction Register เมื่อเป็นการแก้ไขข้อบกพร่อง |
|
||||
|
||||
## Software Unit
|
||||
|
||||
| ID | Description | Functional Interfaces Detail | References | Files |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| UN01 — ผู้ใช้งานและสิทธิ์ (Identity & Access) | | | | |
|
||||
| UN01.001 | Identity – Register & Onboarding | ลงทะเบียนเจ้าของบริษัท, ยืนยันอีเมล, เชิญผู้ใช้และรับคำเชิญเข้าบริษัทที่ถูกต้อง | SR03:001, SR08:001 | app/login/, UserManager.php |
|
||||
| UN01.002 | Identity – Login & Role Guard | เข้าสู่ระบบด้วย Username/Password, ตรวจบทบาทและสิทธิ์แอปพลิเคชันฝั่งเซิร์ฟเวอร์ก่อนเข้าทุกหน้า | SR03:001, SR04:001, SR07:005 | app/login/, UserManager.php, app/assets/utils/ |
|
||||
| UN01.003 | Identity – Password Recovery / OTP / Session | ลืมรหัสผ่านผ่านอีเมล, OTP, Hash รหัสผ่าน bcrypt, บล็อก Concurrent Login | SR03:001, SR01:004, SR07:003 | PasswordManager.php, PasswordResetManager.php |
|
||||
| UN01.004 | Identity – User & App-Access Administration | เพิ่ม/แก้ไข/ปิดใช้ผู้ใช้, กำหนดบทบาทและสิทธิ์การเข้าถึงแอปพลิเคชัน | SR03:001, SR08:001 | app/setting/, UserManager.php |
|
||||
| UN02 — ตั้งค่าบริษัท (Company Settings) | | | | |
|
||||
| UN02.001 | Company – Profile & System Settings | แก้ไขข้อมูลบริษัท, โลโก้, ค่าตั้งค่าระบบต่อบริษัท | SR03:002 | CompanyProfileManager.php, CompanySettingManager.php |
|
||||
| UN02.002 | Company – SMTP & Mail Dispatch | ตั้งค่า SMTP ต่อบริษัท และส่งอีเมล Onboarding/กู้คืนรหัสผ่าน/แจ้งเตือน | SR03:002, SR06:004 | SmtpManager.php |
|
||||
| UN03 — ข้อมูลหลัก (Master Data) | | | | |
|
||||
| UN03.001 | Master – Warehouse / Storage / Bin | จัดการคลังสินค้า พื้นที่ และช่องจัดเก็บ พร้อมความจุ | SR03:003, SR08:002 | app/inventory/, WarehouseManager.php |
|
||||
| UN03.002 | Master – Product & Category | จัดการหมวดสินค้า สินค้า หน่วยนับ และรูปสินค้า | SR03:003, SR08:002 | ProductManager.php |
|
||||
| UN03.003 | Master – Contact | จัดการประเภทผู้ติดต่อ ลูกค้า และผู้ขาย | SR03:003, SR08:002 | app/contact/, ContactManager.php |
|
||||
| UN03.004 | Master – Warehouse Layer Configuration | สลับโครงสร้างคลังแบบชั้นเดียว/หลายชั้นต่อบริษัท | SR03:003 | CompanySettingManager.php, WarehouseManager.php |
|
||||
| UN04 — ควบคุมสินค้าคงคลัง (Inventory Control) | | | | |
|
||||
| UN04.001 | ICS – Stock-in | รับสินค้าเข้าตามสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง สร้างความเคลื่อนไหวและยอดคงเหลือ | SR03:004, SR08:003 | app/ics/, StockManager.php, StockTablesTrait.php |
|
||||
| UN04.002 | ICS – Stock-out | จ่ายสินค้าออกโดยตรวจสิทธิ์และยอดคงเหลือ ปฏิเสธจำนวนเกิน | SR03:004, SR09:003 | StockManager.php |
|
||||
| UN04.003 | ICS – Stock Transfer | โอนย้ายระหว่างตำแหน่ง ต้นทาง/ปลายทางผูกเป็นรายการเดียว | SR03:004 | StockManager.php |
|
||||
| UN04.004 | ICS – Lot / Serial / Expiry | บันทึกและสอบกลับ Lot, Serial Number, วันหมดอายุ | SR03:004, SR08:002 | StockSourceManager.php, md_lot |
|
||||
| UN04.005 | ICS – Barcode Label & Scan | พิมพ์ฉลากบาร์โค้ด SKU/ตำแหน่ง และรับค่าจากเครื่องสแกน | SR03:004 | BarcodeManager.php, location_barcode_label.php |
|
||||
| UN04.006 | ICS – File Attachment | แนบและเรียกดูไฟล์ที่อนุญาตในรายการที่รองรับ | SR03:004 | FileUploader.php |
|
||||
| UN05 — ขาย (Sales) | | | | |
|
||||
| UN05.001 | Sales – Quotation | สร้าง/แก้ไข/อนุมัติใบเสนอราคา และแปลงเป็นใบสั่งขาย | SR03:005, SR04:002 | app/order/, QuotationManager.php |
|
||||
| UN05.002 | Sales – Sales Order | สร้างใบสั่งขาย ยืนยัน และตัดสต๊อกตามสถานะ | SR03:005, SR04:002 | OrderManager.php |
|
||||
| UN05.003 | Sales – Invoice | ออกใบแจ้งหนี้จากใบสั่งขาย และบันทึก GL | SR03:005, SR04:002 | app/revenue/, InvoiceManager.php |
|
||||
| UN05.004 | Sales – Return / Credit Note | รับคืนสินค้าและออกใบลดหนี้ พร้อมปรับสต๊อก/บัญชี | SR03:005, SR04:002 | ReturnManager.php |
|
||||
| UN06 — จัดซื้อ (Purchasing) | | | | |
|
||||
| UN06.001 | Purchasing – Purchase Request | สร้างและอนุมัติใบขอซื้อ | SR03:006 | app/po/, PurchaseRequestManager.php |
|
||||
| UN06.002 | Purchasing – Purchase Order | แปลงใบขอซื้อเป็นใบสั่งซื้อ และติดตามสถานะ | SR03:006, SR04:002 | PurchaseOrderManager.php |
|
||||
| UN06.003 | Purchasing – Purchase Invoice | บันทึกใบแจ้งหนี้ซื้อ รับสินค้าเข้า และบันทึก GL | SR03:006, SR04:002 | PurchaseOrderManager.php, StockManager.php |
|
||||
| UN06.004 | Purchasing – Supplier Return | คืนสินค้าผู้ขาย พร้อมปรับสต๊อก/บัญชี | SR03:006, SR04:002 | SupplierReturnManager.php |
|
||||
| UN07 — การเงิน (Finance) | | | | |
|
||||
| UN07.001 | Finance – Receipt Billing & Receipt | วางบิลรับและบันทึกใบเสรจรับเงินผูกกับใบแจ้งหนี้ | SR03:007, SR04:002 | app/finance/, ReceiptBillingManager.php, ReceiptManager.php |
|
||||
| UN07.002 | Finance – Payment Billing & Payment | วางบิลจ่ายและบันทึกใบสำคัญจ่ายผูกกับใบแจ้งหนี้ซื้อ | SR03:007, SR04:002 | PaymentBillingManager.php, PaymentManager.php |
|
||||
| UN08 — บัญชี (Accounting) | | | | |
|
||||
| UN08.001 | Accounting – Chart of Accounts / Departments / Formulas | จัดการผังบัญชี แผนก และสูตรบัญชีอัตโนมัติ | SR03:008, SR08:002 | app/accounting/, PostingManager.php |
|
||||
| UN08.002 | Accounting – Journal & GL Posting | บันทึกสมุดรายวันและผ่านรายการ GL แบบสมดุลภายใน Transaction | SR03:008, SR09:003 | app/journal/, PostingManager.php |
|
||||
| UN09 — รายงานและแดชบอร์ด (Reports & Dashboard) | | | | |
|
||||
| UN09.001 | Reports – Dashboard & Aggregates | แดชบอร์ดคลังสินค้าและบัญชีจากตารางสรุปยอด | SR03:009, SR05:001, SR05:002 | app/dashboard/, app/ac_dashboard/, EtlStockManager.php |
|
||||
| UN09.002 | Reports – Stock Reports | ภาพรวมสต๊อก, ความเคลื่อนไหว, ความจุ, สินค้าใกล้หมด, หมดอายุ, Lot | SR03:009 | app/reports/, ReportManager.php |
|
||||
| UN09.003 | Reports – Financial Reports | งบทดลอง, งบกำไรขาดทุน, งบดุล, VAT, สมุดรายวัน, ความเคลื่อนไหว GL | SR03:009 | ReportManager.php |
|
||||
| UN09.004 | Reports – Filter / Print / Export | กรอง ดู พิมพ์ และส่งออกรายงานตามขอบเขตสิทธิ์ | SR03:009, SR04:003 | app/reports/ |
|
||||
| UN10 — ควบคุมเอกสาร (Document Control) | | | | |
|
||||
| UN10.001 | Document – Numbering | ออกเลขที่เอกสารตามลำดับที่กำหนด (document_number_sequences) | SR03:010, SR04:005, SR08:004 | DocumentNumberManager.php |
|
||||
| UN10.002 | Document – Lifecycle & Status | ควบคุมสถานะเอกสาร ปฏิเสธการเปลี่ยนสถานะที่ไม่ถูกต้อง พร้อม Confirm Dialog และข้อความข้อผิดพลาด | SR03:010, SR09:001, SR09:002 | BatchActionManager.php, Manager classes |
|
||||
| UN10.003 | Document – Audit Fields & History | บันทึกผู้สร้าง ผู้แก้ไข วันที่ และประวัติรายการ | SR03:010, SR09:001 | td_* tables, td_bin_log |
|
||||
| UN11 — แจ้งเตือนและงานตามกำหนดเวลา (Notification & Scheduler) | | | | |
|
||||
| UN11.001 | Node – Socket.IO Notification Server | รับเหตุการณ์จาก PHP ผ่าน Endpoint ที่ป้องกันด้วย Secret และส่งต่อไปยัง Browser ของผู้ใช้ที่เกี่ยวข้อง | SR03:011, SR04:004, SR06:004, SR06:005 | nodejs/server.js |
|
||||
| UN11.002 | Node – Scheduler (ETL & Alerts) | สรุปยอดสต๊อก/GL, แจ้งเตือนสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระ ตามกำหนดเวลา Asia/Bangkok | SR03:011, SR05:002, SR01:006 | nodejs/scheduler.js, app/cron/ |
|
||||
| UN12 — ความปลอดภัยและการแยกข้อมูล (Security & Tenant Scope) | | | | |
|
||||
| UN12.001 | Security – Tenant Scope Guard | จำกัดทุก Query และ Action ให้อยู่ในบริษัท/คลังที่ผู้ใช้ได้รับอนุญาต | SR04:001, SR04:003, SR07:002 | StockTablesTrait.php, Manager classes |
|
||||
| UN12.002 | Security – Server-side Validation | ตรวจสอบข้อมูลนำเข้า, Prepared Statements, Escape Output ป้องกัน SQLi/XSS | SR07:002, SR07:004 | Manager classes, app/assets/utils/ |
|
||||
| UN12.003 | Security – Operation Lock & Usage Guard | ล็อกช่วงเวลาผ่านรายการ และจำกัดโควตารายการต่อบริษัท | SR07:002, SR09:003 | OperationLockManager.php, UsageGuard.php |
|
||||
| UN12.004 | Security – TLS & Secret Configuration | ค่าตั้งค่า TLS, NODE_EMIT_SECRET และ Secrets ที่สร้างตอนติดตั้ง | SR07:001, SR01:005 | docker/php/config.php.template, .env |
|
||||
| UN13 — ติดตั้งและสำรองข้อมูล (Deployment & Backup) | | | | |
|
||||
| UN13.001 | Deploy – setup.php Schema Installer | สร้างฐานข้อมูล wms/wms2 และตารางทั้งหมดในขั้นตอนเดียว | SR01:003, SR08:005, SR06:001 | setup.php, docker/mariadb/init-wms2.sql |
|
||||
| UN13.002 | Deploy – Docker Compose Stack | Container php-apache, mariadb, node/pm2 พร้อม Entrypoint สร้าง config.php | SR02:005, SR01:003 | docker-compose.yml, docker/ |
|
||||
| UN13.003 | Deploy – .env Generator | สร้าง .env และความลับอัตโนมัติ ไม่เก็บใน Git | SR01:005 | docker/init-env.sh, .env.example |
|
||||
| UN13.004 | Deploy – Backup & Restore | สำรอง Git 2 Remote, mysqldump รายวัน, ขั้นตอนกู้คืน | SR01:003 | Product Operation Guide, backup remote |
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-121
@@ -1,121 +0,0 @@
|
||||
# Software Design
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Design |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | System Design Document |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Recorder | Thanakorn Sathitwitayakul — Developer |
|
||||
| Status | Final — describes the as-built architecture; from the current codebase |
|
||||
|
||||
## Basis
|
||||
|
||||
This design was derived from the current repository structure and class list rather than authored before implementation. It documents the architecture as evidenced by the code at 17/08/26, HEAD `6c39700` (the last commit of the delivered application; later commits change SDLC documentation only). Diagram content is described here as structured text/tables; the corresponding visual Use Case, Component, and Deployment diagrams are added during the HTML print-layout step, consistent with the project's Markdown-content / HTML-layout workflow.
|
||||
|
||||
## HIGH LEVEL DESIGN
|
||||
|
||||
### Use case actors and actions
|
||||
|
||||
| Actor | Description | Representative actions |
|
||||
|---|---|---|
|
||||
| Owner | Company owner; highest-privilege role within a company | Full access to configuration, users, and all operational modules within the company |
|
||||
| Admin | Administrative user within a company | Manage company settings, users, application access, and all operational modules |
|
||||
| Staff | Operational user | Perform warehouse, sales, purchasing, and finance transactions within permitted scope |
|
||||
| Viewer | Read-only user | View authorized screens and reports without creating/editing transactions |
|
||||
| System (Node.js scheduler) | Automated actor | Executes scheduled stock/GL aggregate maintenance and low-stock/overdue-invoice alerts |
|
||||
| Email/SMTP service | External actor | Delivers onboarding, password-reset, and notification email sent by the application |
|
||||
|
||||
### Component layers
|
||||
|
||||
| Layer | Composition | SR reference |
|
||||
|---|---|---|
|
||||
| Presentation | PHP page views under each `app/<module>/` directory; responsive UI; `app/assets/js/custom.js` and supporting JS/CSS | SR02:002, SR06:002, SR06:003 |
|
||||
| Business logic | 31 manager/service classes plus one shared trait (32 files) in `app/assets/utils/classes/` (Section "Software Unit" below), invoked from page controllers | SR02:003, SR03:001–SR03:011 |
|
||||
| Data access | Manager classes query two MariaDB databases directly (no separate ORM layer); `StockTablesTrait` centralizes shared stock-table access patterns | SR02:004, SR06:001, SR08:001–SR08:005 |
|
||||
| Real-time/scheduled services | Node.js `server.js` (Socket.IO notification relay) and `scheduler.js` (cron-style aggregate/alert jobs), managed by pm2 (`ecosystem.config.js`) | SR03:011, SR06:004, SR06:005 |
|
||||
| External integration | SMTP email delivery (`SmtpManager`); browser Socket.IO client for real-time notifications | SR06:004, SR06:005 |
|
||||
|
||||
### Deployment tiers
|
||||
|
||||
| Tier | Composition | SR reference |
|
||||
|---|---|---|
|
||||
| Client | Browser (Chrome/Edge/Firefox), responsive UI, Socket.IO client connection | SR06:002, SR06:003, SR06:005 |
|
||||
| Web tier | PHP 8+ application; manual LAMP install (`setup.php`) or `docker/php` container (php-apache, config generated from `.env` at entrypoint) | SR01:003, SR02:005 |
|
||||
| Data tier | MariaDB, two databases: `wms` (identity/company) and `wms2` (WMS/accounting); manual install or `docker/mariadb` container | SR06:001, SR08:001–SR08:004 |
|
||||
| Real-time/scheduler tier | Node.js `server.js` + `scheduler.js` under pm2; manual install or `docker/node` container | SR03:011, SR06:004, SR06:005 |
|
||||
| External | SMTP server (configured per company via `company_smtp`) | SR06:004 |
|
||||
|
||||
## Software Unit
|
||||
|
||||
One unit per business-logic manager class, plus the two Node.js services. Each unit's SR reference is its owning module in the SRS (Section SR03).
|
||||
|
||||
| ID | Description | Functional interfaces detail | SR reference |
|
||||
|---|---|---|---|
|
||||
| UN01 | `UserManager` | User CRUD, role assignment, application-access flags | SR03:001 |
|
||||
| UN02 | `PasswordManager` | Password hashing (bcrypt), validation, change | SR03:001, SR01:004 |
|
||||
| UN03 | `PasswordResetManager` | Forgot-password token issuance and reset flow | SR03:001 |
|
||||
| UN04 | `CompanyProfileManager` | Company profile CRUD | SR03:002 |
|
||||
| UN05 | `CompanySettingManager` | Company-level system settings | SR03:002 |
|
||||
| UN06 | `SmtpManager` | Per-company SMTP configuration and mail dispatch | SR03:002, SR06:004 |
|
||||
| UN07 | `WarehouseManager` | Warehouse/storage/bin master data and capacity/occupancy | SR03:003, SR03:004 |
|
||||
| UN08 | `ProductManager` | Product and product-category master data | SR03:003 |
|
||||
| UN09 | `ContactManager` | Contact type and contact master data | SR03:003 |
|
||||
| UN10 | `StockManager` | Stock-in/out/transfer, lot/serial/expiry, balances | SR03:004 |
|
||||
| UN11 | `StockSourceManager` | Stock source/traceability resolution | SR03:004 |
|
||||
| UN12 | `StockTablesTrait` | Shared stock-table query/aggregation logic reused by stock-facing managers | SR03:004 |
|
||||
| UN13 | `BarcodeManager` | SKU/location barcode label generation and scan handling | SR03:004 |
|
||||
| UN14 | `EtlStockManager` | Stock aggregate (ETL) table maintenance | SR03:009, SR05:002 |
|
||||
| UN15 | `QuotationManager` | Quotation lifecycle | SR03:005 |
|
||||
| UN16 | `OrderManager` | Sales-order lifecycle | SR03:005 |
|
||||
| UN17 | `InvoiceManager` | Sales-invoice lifecycle | SR03:005 |
|
||||
| UN18 | `ReturnManager` | Sales-return / credit-note lifecycle | SR03:005 |
|
||||
| UN19 | `PurchaseRequestManager` | Purchase-request lifecycle | SR03:006 |
|
||||
| UN20 | `PurchaseOrderManager` | Purchase-order lifecycle | SR03:006 |
|
||||
| UN21 | `SupplierReturnManager` | Supplier-return lifecycle | SR03:006 |
|
||||
| UN22 | `ReceiptBillingManager` | Receipt billing lifecycle | SR03:007 |
|
||||
| UN23 | `ReceiptManager` | Receipt lifecycle | SR03:007 |
|
||||
| UN24 | `PaymentBillingManager` | Payment billing lifecycle | SR03:007 |
|
||||
| UN25 | `PaymentManager` | Payment lifecycle | SR03:007 |
|
||||
| UN26 | `PostingManager` | Chart of accounts, account formulas, journal, GL posting | SR03:008 |
|
||||
| UN27 | `ReportManager` | Operational and financial report generation | SR03:009 |
|
||||
| UN28 | `DocumentNumberManager` | Controlled document-number sequence generation | SR03:010 |
|
||||
| UN29 | `BatchActionManager` | Bulk/batch record operations | SR02:003 |
|
||||
| UN30 | `OperationLockManager` | Posting-window / operation-lock enforcement | SR07:002, SR09:003 |
|
||||
| UN31 | `UsageGuard` | Company usage-package/transaction-quota enforcement | SR07:002 |
|
||||
| UN32 | `FileUploader` | Supported file-attachment upload handling | SR03:004 |
|
||||
| UN33 | `nodejs/server.js` | Socket.IO real-time notification relay | SR03:011, SR06:005 |
|
||||
| UN34 | `nodejs/scheduler.js` | Scheduled stock/GL aggregate maintenance and low-stock/overdue-invoice alerts | SR03:011, SR05:002 |
|
||||
|
||||
## User Interface Design
|
||||
|
||||
The delivered UI is an implemented, responsive PHP application (login, dashboard, warehouse/inventory, sales, purchasing, finance, accounting, reports, settings). Because the UI already exists as running screens rather than pre-implementation mockups, wireframe capture is not reproduced here; representative screenshots are added during the HTML print-layout step where useful, consistent with the Software User Documentation (work product 18), which documents actual screens.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+146
@@ -0,0 +1,146 @@
|
||||
# Traceability Record
|
||||
|
||||
<!-- footer: TR -->
|
||||
|
||||
| Document No | Traceability Record | Release, Version, By: | 25690306 V1.0 NoC |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารบันทึกการสอบกลับได้ของระบบ (Traceability Matrix) |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เอกสารที่เชื่อมโยงทุกขั้นตอนของโครงการ ตั้งแต่ความต้องการของลูกค้า → ความต้องการซอฟต์แวร์ → การออกแบบ → การทดสอบ เพื่อยืนยันความครบถ้วนของ Customer Requirements และลดความเสี่ยงของข้อบกพร่องและความต้องการที่ตกหล่น
|
||||
|
||||
## Traceability Matrix
|
||||
|
||||
| CR ID | CR Topic | SRS ID | SRS Topic | Unit ID | Unit Topic | Test Case ID |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| CR01: Feature & Functional Characteristics | | | | | | |
|
||||
| CR01:001 | ระบบต้องรองรับการลงทะเบียนเจ้าของบริษัทและการเชิญผู้ใช้งานเข้าร่วมบริษัท (Onboarding) | SR03:001, SR08:001 | โมดูลผู้ใช้งานและสิทธิ์: ลงทะเบียน, Onboarding, เข้าสู่ระบบ, บทบาท Owner/Admin/Staff/Viewer, สิทธิ์แอปพลิเคชัน (app/login/, UserManager, PasswordManager, PasswordResetManager) / ฐานข้อมูล wms: user, company_list, company_map_user, company_setting, company_smtp, company_usage, whitelist | UN01.001 | Identity – Register & Onboarding | TC-UN01.001 |
|
||||
| CR01:002 | ระบบต้องยืนยันตัวตนผู้ใช้และบังคับสิทธิ์ตามบทบาท Owner, Admin, Staff และ Viewer | SR03:001, SR04:001, SR07:005 | โมดูลผู้ใช้งานและสิทธิ์: ลงทะเบียน, Onboarding, เข้าสู่ระบบ, บทบาท Owner/Admin/Staff/Viewer, สิทธิ์แอปพลิเคชัน (app/login/, UserManager, PasswordManager, PasswordResetManager) / ทุกโมดูลปฏิบัติการต้องเข้าถึงได้ผ่านการยืนยันตัวตนและการตรวจสิทธิ์ของโมดูลผู้ใช้งานเท่านั้น / RBAC (Owner/Admin/Staff/Viewer) ต้องบังคับใช้ที่ฝั่งเซิร์ฟเวอร์ ไม่ใช่เพียงการซ่อนเมนู | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR01:003 | ระบบต้องรองรับการกู้คืนรหัสผ่าน การควบคุม Session และการยืนยัน OTP ตามที่กำหนด | SR03:001, SR07:003 | โมดูลผู้ใช้งานและสิทธิ์: ลงทะเบียน, Onboarding, เข้าสู่ระบบ, บทบาท Owner/Admin/Staff/Viewer, สิทธิ์แอปพลิเคชัน (app/login/, UserManager, PasswordManager, PasswordResetManager) / ระบบต้องอนุญาต Session ที่ใช้งานอยู่เพียงหนึ่งต่อบัญชี (บล็อก Concurrent Login) | UN01.003 | Identity – Password Recovery / OTP / Session | TC-UN01.003 |
|
||||
| CR01:004 | ระบบต้องให้ผู้ดูแลจัดการข้อมูลบริษัท, SMTP, การตั้งค่าระบบ, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน | SR03:001, SR03:002 | โมดูลผู้ใช้งานและสิทธิ์: ลงทะเบียน, Onboarding, เข้าสู่ระบบ, บทบาท Owner/Admin/Staff/Viewer, สิทธิ์แอปพลิเคชัน (app/login/, UserManager, PasswordManager, PasswordResetManager) / โมดูลตั้งค่าบริษัท: ข้อมูลบริษัท, SMTP, การตั้งค่าระบบ (app/setting/, CompanyProfileManager, CompanySettingManager, SmtpManager) | UN01.004, UN02.001, UN02.002 | Identity – User & App-Access Administration / Company – Profile & System Settings / Company – SMTP & Mail Dispatch | TC-UN01.004 |
|
||||
| CR01:005 | ระบบต้องจัดการข้อมูลคลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ประเภทผู้ติดต่อ และผู้ติดต่อ | SR03:003, SR08:002 | โมดูลข้อมูลหลัก: คลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ผู้ติดต่อ (app/inventory/, app/contact/, WarehouseManager, ProductManager, ContactManager) / ตารางข้อมูลหลัก (wms2): md_warehouse, md_storage, md_bin, md_product, md_product_category, md_contact, md_contact_type, md_account, md_account_formula, md_account_formula_item, md_department, md_barcode, md_sku_barcode_label, md_lot, md_lock_operation | UN03.001, UN03.002, UN03.003 | Master – Warehouse / Storage / Bin / Master – Product & Category / Master – Contact | TC-UN03.001 |
|
||||
| CR01:006 | ระบบต้องรองรับโครงสร้างตำแหน่งจัดเก็บทั้งแบบคลังเดียวและแบบหลายชั้น (คลัง/พื้นที่/ช่อง) | SR03:003 | โมดูลข้อมูลหลัก: คลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ผู้ติดต่อ (app/inventory/, app/contact/, WarehouseManager, ProductManager, ContactManager) | UN03.004 | Master – Warehouse Layer Configuration | TC-UN03.004 |
|
||||
| CR01:007 | ระบบต้องบันทึกการรับสินค้าเข้า (Stock-in) ระบุสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง และข้อมูลติดตาม | SR03:004, SR08:003 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) / ตารางรายการ (td_*): td_stock, td_order/_item, td_quotation/_item, td_invoice/_item, td_return/_item, td_purchase_request/_item, td_purchase_order/_item, td_supplier_return/_item, td_receipt/_item, td_receipt_billing/_item, td_payment/_item, td_payment_billing/_item, td_gl/td_gl_item, td_batch_action, td_bin_log | UN04.001 | ICS – Stock-in | TC-UN04.001 |
|
||||
| CR01:008 | ระบบต้องบันทึกการจ่ายสินค้าออก (Stock-out) โดยตรวจสอบสิทธิ์และยอดคงเหลือก่อนจ่าย | SR03:004, SR09:003 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) / การเปลี่ยนแปลงที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction และป้องกันยอดติดลบ/ซ้ำ | UN04.002 | ICS – Stock-out | TC-UN04.002 |
|
||||
| CR01:009 | ระบบต้องโอนย้ายสินค้าระหว่างตำแหน่งจัดเก็บที่ได้รับอนุญาตโดยยอดต้นทาง/ปลายทางสมดุลกัน | SR03:004 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) | UN04.003 | ICS – Stock Transfer | TC-UN04.003 |
|
||||
| CR01:010 | ระบบต้องติดตาม Lot, Serial Number และวันหมดอายุของสินค้าที่เกี่ยวข้อง | SR03:004, SR08:002 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) / ตารางข้อมูลหลัก (wms2): md_warehouse, md_storage, md_bin, md_product, md_product_category, md_contact, md_contact_type, md_account, md_account_formula, md_account_formula_item, md_department, md_barcode, md_sku_barcode_label, md_lot, md_lock_operation | UN04.004 | ICS – Lot / Serial / Expiry | TC-UN04.004 |
|
||||
| CR01:011 | ระบบต้องแสดงภาพรวมสต๊อก, ประวัติความเคลื่อนไหว, ความจุ/การใช้พื้นที่, สินค้าใกล้หมด, สินค้าหมดอายุ และข้อมูล Lot | SR03:009 | โมดูลรายงานและแดชบอร์ด: รายงานสต๊อก, รายงานการเงิน, แดชบอร์ด (app/reports/, app/dashboard/, app/ac_dashboard/, ReportManager, EtlStockManager) | UN09.002 | Reports – Stock Reports | TC-UN09.002 |
|
||||
| CR01:012 | ระบบต้องพิมพ์บาร์โค้ดสินค้า (SKU) และตำแหน่งจัดเก็บ และรองรับการสแกนในหน้าจอที่กำหนด | SR03:004 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) | UN04.005 | ICS – Barcode Label & Scan | TC-UN04.005 |
|
||||
| CR01:013 | ระบบต้องสร้างและจัดการใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน และใบลดหนี้ | SR03:005, SR04:002 | โมดูลขาย: ใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน/ใบลดหนี้ (app/order/, app/revenue/, QuotationManager, OrderManager, InvoiceManager, ReturnManager) / โมดูลขาย จัดซื้อ และการเงิน ต้องบันทึกผลกระทบต่อสต๊อกและ GL ผ่านโมดูลคลังสินค้าและบัญชี ไม่ทำซ้ำตรรกะ | UN05.001, UN05.002, UN05.003, UN05.004 | Sales – Quotation / Sales – Sales Order / Sales – Invoice / Sales – Return / Credit Note | TC-UN05.001 |
|
||||
| CR01:014 | ระบบต้องสร้างและจัดการใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ และใบคืนสินค้าผู้ขาย | SR03:006, SR04:002 | โมดูลจัดซื้อ: ใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ, ใบคืนสินค้าผู้ขาย (app/po/, PurchaseRequestManager, PurchaseOrderManager, SupplierReturnManager) / โมดูลขาย จัดซื้อ และการเงิน ต้องบันทึกผลกระทบต่อสต๊อกและ GL ผ่านโมดูลคลังสินค้าและบัญชี ไม่ทำซ้ำตรรกะ | UN06.001, UN06.002, UN06.003, UN06.004 | Purchasing – Purchase Request / Purchasing – Purchase Order / Purchasing – Purchase Invoice / Purchasing – Supplier Return | TC-UN06.001 |
|
||||
| CR01:015 | ระบบต้องสร้างและจัดการใบวางบิลรับ, ใบเสร็จรับเงิน, ใบวางบิลจ่าย และใบสำคัญจ่าย | SR03:007, SR04:002 | โมดูลการเงิน: ใบวางบิลรับ, ใบเสร็จ, ใบวางบิลจ่าย, ใบสำคัญจ่าย (app/finance/, ReceiptBillingManager, ReceiptManager, PaymentBillingManager, PaymentManager) / โมดูลขาย จัดซื้อ และการเงิน ต้องบันทึกผลกระทบต่อสต๊อกและ GL ผ่านโมดูลคลังสินค้าและบัญชี ไม่ทำซ้ำตรรกะ | UN07.001, UN07.002 | Finance – Receipt Billing & Receipt / Finance – Payment Billing & Payment | TC-UN07.001 |
|
||||
| CR01:016 | ระบบต้องจัดการผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน และบัญชีแยกประเภท | SR03:008 | โมดูลบัญชี: ผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน, บัญชีแยกประเภท (app/accounting/, app/journal/, PostingManager) | UN08.001, UN08.002 | Accounting – Chart of Accounts / Departments / Formulas / Accounting – Journal & GL Posting | TC-UN08.001 |
|
||||
| CR01:017 | ระบบต้องจัดทำรายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม, สมุดรายวัน และความเคลื่อนไหว GL | SR03:009 | โมดูลรายงานและแดชบอร์ด: รายงานสต๊อก, รายงานการเงิน, แดชบอร์ด (app/reports/, app/dashboard/, app/ac_dashboard/, ReportManager, EtlStockManager) | UN09.003 | Reports – Financial Reports | TC-UN09.003 |
|
||||
| CR01:018 | ระบบต้องออกเลขที่เอกสารอัตโนมัติและควบคุมสถานะ/วงจรชีวิตของเอกสาร | SR03:010, SR04:005, SR08:004 | โมดูลควบคุมเอกสาร: ออกเลขที่เอกสาร, วงจรชีวิต/สถานะ, ประวัติรายการ (DocumentNumberManager, BatchActionManager) / ทุกโมดูลที่สร้างเอกสารธุรกิจต้องเรียกใช้โมดูลควบคุมเอกสารเพื่อออกเลขที่เอกสาร / ตารางสรุปยอดและควบคุมเอกสาร: etl_stock_summary, etl_gl_summary, document_number_sequences, document_types, schema_migrations | UN10.001, UN10.002 | Document – Numbering / Document – Lifecycle & Status | TC-UN10.001 |
|
||||
| CR01:019 | ระบบต้องรองรับการแนบไฟล์ที่อนุญาตกับรายการที่กำหนด | SR03:004 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) | UN04.006 | ICS – File Attachment | TC-UN04.006 |
|
||||
| CR01:020 | ระบบต้องให้ผู้ใช้กรอง ดู พิมพ์ และส่งออกรายงานปฏิบัติการและรายงานผู้บริหาร | SR03:009 | โมดูลรายงานและแดชบอร์ด: รายงานสต๊อก, รายงานการเงิน, แดชบอร์ด (app/reports/, app/dashboard/, app/ac_dashboard/, ReportManager, EtlStockManager) | UN09.004 | Reports – Filter / Print / Export | TC-UN09.004 |
|
||||
| CR01:021 | ระบบต้องแจ้งเตือนผู้ใช้ที่เกี่ยวข้องเมื่อสถานะเอกสารเปลี่ยนหรือมีเหตุการณ์ปฏิบัติการ | SR03:011, SR04:004, SR06:005 | บริการแจ้งเตือนและงานตามกำหนดเวลา: Socket.IO และ Scheduler (nodejs/server.js, nodejs/scheduler.js, app/cron/) / บริการ Node.js ต้องรับเหตุการณ์จากแอปพลิเคชัน PHP ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret เท่านั้น / Browser ต้องเชื่อมต่อ Socket.IO Endpoint (NODE_PUBLIC_URL) เพื่อรับการแจ้งเตือน | UN11.001 | Node – Socket.IO Notification Server | TC-UN11.001 |
|
||||
| CR01:022 | ระบบต้องสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระตามกำหนดเวลา | SR03:011, SR05:002, SR08:004 | บริการแจ้งเตือนและงานตามกำหนดเวลา: Socket.IO และ Scheduler (nodejs/server.js, nodejs/scheduler.js, app/cron/) / ยอดสรุปสต๊อก/GL/แดชบอร์ดต้องคำนวณล่วงหน้าตามกำหนดเวลา (etl_stock_summary, etl_gl_summary) / ตารางสรุปยอดและควบคุมเอกสาร: etl_stock_summary, etl_gl_summary, document_number_sequences, document_types, schema_migrations | UN11.002 | Node – Scheduler (ETL & Alerts) | TC-UN11.002 |
|
||||
| CR01:023 | ระบบต้องเก็บผู้สร้าง ผู้แก้ไข สถานะ และประวัติรายการเพื่อการตรวจสอบ | SR03:010, SR09:001 | โมดูลควบคุมเอกสาร: ออกเลขที่เอกสาร, วงจรชีวิต/สถานะ, ประวัติรายการ (DocumentNumberManager, BatchActionManager) / การลบ ยกเลิก หรือ Void เอกสารควบคุมต้องมี Confirm Dialog | UN10.003 | Document – Audit Fields & History | TC-UN10.003 |
|
||||
| CR01:024 | ระบบต้องจำกัดข้อมูลบริษัทและคลังสินค้าให้เฉพาะผู้ใช้ที่ได้รับอนุญาตในบริบทปัจจุบัน | SR04:001, SR04:003, SR07:002 | ทุกโมดูลปฏิบัติการต้องเข้าถึงได้ผ่านการยืนยันตัวตนและการตรวจสิทธิ์ของโมดูลผู้ใช้งานเท่านั้น / โมดูลรายงานต้องอ่านข้อมูลภายใต้ขอบเขตบริษัท/คลังที่โมดูลข้อมูลหลักและคลังสินค้าบังคับใช้ / การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | UN12.001 | Security – Tenant Scope Guard | TC-UN12.001 |
|
||||
| CR02: Performance Considerations | | | | | | |
|
||||
| CR02:001 | ระบบต้องตอบสนองงานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | SR05:001 | งานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ต้องเสร็จภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | UN09.001 | Reports – Dashboard & Aggregates | TC-UN09.001 |
|
||||
| CR02:002 | ระบบต้องมีตารางสรุปยอด (Aggregate) เพื่อให้แดชบอร์ดและรายงานแสดงผลได้โดยไม่ต้องคำนวณใหม่ทุกครั้ง | SR05:002 | ยอดสรุปสต๊อก/GL/แดชบอร์ดต้องคำนวณล่วงหน้าตามกำหนดเวลา (etl_stock_summary, etl_gl_summary) | UN09.001, UN11.002 | Reports – Dashboard & Aggregates / Node – Scheduler (ETL & Alerts) | TC-UN09.001 |
|
||||
| CR02:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันในระดับที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | SR05:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันตามที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | UN09.001 | Reports – Dashboard & Aggregates | TC-UN09.001 |
|
||||
| CR03: Interface Considerations | | | | | | |
|
||||
| CR03:001 | ระบบต้องเชื่อมต่อฐานข้อมูล MySQL/MariaDB 2 ฐาน (wms สำหรับผู้ใช้/บริษัท และ wms2 สำหรับคลัง/บัญชี) | SR06:001 | แอปพลิเคชัน PHP ต้องเชื่อมต่อฐานข้อมูล MariaDB 2 ฐาน: wms (ผู้ใช้/บริษัท) และ wms2 (คลัง/บัญชี) | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR03:002 | ระบบต้องใช้งานผ่าน Web Browser มาตรฐาน (Chrome, Edge, Firefox) ได้ | SR06:002 | ระบบต้องใช้งานได้บน Chrome, Edge และ Firefox รุ่นปัจจุบัน | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR03:003 | ระบบต้องส่งเหตุการณ์ไปยังบริการ Node.js ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret | SR06:004, SR04:004 | แอปพลิเคชัน PHP ต้องส่งเหตุการณ์ไป Node.js ผ่าน HTTP Endpoint ภายใน (NODE_EMIT_URL + NODE_EMIT_SECRET) และส่งอีเมลผ่าน SMTP ต่อบริษัท / บริการ Node.js ต้องรับเหตุการณ์จากแอปพลิเคชัน PHP ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret เท่านั้น | UN11.001 | Node – Socket.IO Notification Server | TC-UN11.001 |
|
||||
| CR03:004 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint สาธารณะเพื่อรับการแจ้งเตือนแบบ Real-time | SR06:005 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint (NODE_PUBLIC_URL) เพื่อรับการแจ้งเตือน | UN11.001 | Node – Socket.IO Notification Server | TC-UN11.001 |
|
||||
| CR03:005 | ระบบต้องส่งอีเมล Onboarding, กู้คืนรหัสผ่าน และแจ้งเตือนผ่าน SMTP ที่ตั้งค่าต่อบริษัท | SR06:004, SR03:002 | แอปพลิเคชัน PHP ต้องส่งเหตุการณ์ไป Node.js ผ่าน HTTP Endpoint ภายใน (NODE_EMIT_URL + NODE_EMIT_SECRET) และส่งอีเมลผ่าน SMTP ต่อบริษัท / โมดูลตั้งค่าบริษัท: ข้อมูลบริษัท, SMTP, การตั้งค่าระบบ (app/setting/, CompanyProfileManager, CompanySettingManager, SmtpManager) | UN02.002 | Company – SMTP & Mail Dispatch | TC-UN02.002 |
|
||||
| CR04: Required System Characteristics | | | | | | |
|
||||
| CR04:001 | ระบบต้องพัฒนาบนสถาปัตยกรรม Web-based Application | SR02:001 | ระบบต้องเป็น Web-based Application แบบหลายหน้า (Multi-page PHP) | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR04:002 | ระบบต้องเก็บข้อมูลแบบ Relational Database และรักษา Referential Integrity | SR08:001, SR08:002, SR08:003 | ฐานข้อมูล wms: user, company_list, company_map_user, company_setting, company_smtp, company_usage, whitelist / ตารางข้อมูลหลัก (wms2): md_warehouse, md_storage, md_bin, md_product, md_product_category, md_contact, md_contact_type, md_account, md_account_formula, md_account_formula_item, md_department, md_barcode, md_sku_barcode_label, md_lot, md_lock_operation / ตารางรายการ (td_*): td_stock, td_order/_item, td_quotation/_item, td_invoice/_item, td_return/_item, td_purchase_request/_item, td_purchase_order/_item, td_supplier_return/_item, td_receipt/_item, td_receipt_billing/_item, td_payment/_item, td_payment_billing/_item, td_gl/td_gl_item, td_batch_action, td_bin_log | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR04:003 | ระบบต้องรองรับการเข้าสู่ระบบด้วย Username/Password และกำหนดบทบาทผู้ใช้ | SR04:001 | ทุกโมดูลปฏิบัติการต้องเข้าถึงได้ผ่านการยืนยันตัวตนและการตรวจสิทธิ์ของโมดูลผู้ใช้งานเท่านั้น | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR04:004 | ระบบต้องทำงานบน PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js | SR01:002 | ระบบต้องใช้เทคโนโลยี PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js (Socket.IO, pm2) | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR05: Human Engineering Considerations | | | | | | |
|
||||
| CR05:001 | UI ต้องเป็น Responsive ใช้งานได้ทั้งบน Desktop และอุปกรณ์หน้าคลังสินค้า (Tablet/Mobile) | SR02:002 | ส่วนติดต่อผู้ใช้ต้องเป็น Responsive Design รองรับ Desktop / Tablet / Mobile | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR05:002 | เมนูและปุ่มคำสั่งต้องแสดงตามบทบาทและสิทธิ์การเข้าถึงของผู้ใช้ | SR04:001 | ทุกโมดูลปฏิบัติการต้องเข้าถึงได้ผ่านการยืนยันตัวตนและการตรวจสิทธิ์ของโมดูลผู้ใช้งานเท่านั้น | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR05:003 | ระบบต้องแสดงผลการตรวจสอบข้อมูล สถานะ ความสำเร็จ และข้อผิดพลาดอย่างชัดเจน | SR09:002 | ข้อผิดพลาดต้องแสดงข้อความที่ผู้ใช้เข้าใจได้แทน Fatal Error | UN10.002 | Document – Lifecycle & Status | TC-UN10.002 |
|
||||
| CR05:004 | ระบบต้องมีขั้นตอนยืนยันก่อนลบ ยกเลิก หรือทำรายการที่ย้อนกลับไม่ได้ | SR09:001 | การลบ ยกเลิก หรือ Void เอกสารควบคุมต้องมี Confirm Dialog | UN10.002 | Document – Lifecycle & Status | TC-UN10.002 |
|
||||
| CR05:005 | ระบบต้องพิมพ์เอกสารธุรกิจและฉลากบาร์โค้ดในรูปแบบที่ใช้งานได้ | SR03:004 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) | UN04.005 | ICS – Barcode Label & Scan | TC-UN04.005 |
|
||||
| CR06: Security Considerations | | | | | | |
|
||||
| CR06:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องเข้ารหัสด้วย HTTPS/TLS | SR07:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องผ่าน HTTPS/TLS | UN12.004 | Security – TLS & Secret Configuration | TC-UN12.004 |
|
||||
| CR06:002 | ค่าตั้งค่าและความลับของระบบต้องไม่ถูกเก็บใน Source Control และไม่เข้าถึงได้จากเว็บสาธารณะ | SR01:005 | ค่าตั้งค่าและความลับ (app/config.php, .env) ต้องถูกยกเว้นจาก Source Control และสร้างขึ้นตอนติดตั้ง | UN13.003, UN12.004 | Deploy – .env Generator / Security – TLS & Secret Configuration | TC-UN13.003 |
|
||||
| CR06:003 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | SR07:002 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | UN12.002 | Security – Server-side Validation | TC-UN12.002 |
|
||||
| CR06:004 | ระบบต้องจำกัดสิทธิ์การเข้าถึงตามบทบาท (Role-based Access Control) ทั้งใน UI และฝั่งเซิร์ฟเวอร์ | SR07:005 | RBAC (Owner/Admin/Staff/Viewer) ต้องบังคับใช้ที่ฝั่งเซิร์ฟเวอร์ ไม่ใช่เพียงการซ่อนเมนู | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR06:005 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting | SR07:004 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting ทั้งด้านรับข้อมูลและแสดงผล | UN12.002 | Security – Server-side Validation | TC-UN12.002 |
|
||||
| CR06:006 | ระบบต้องบล็อกการเข้าสู่ระบบซ้ำซ้อน (Concurrent Login) ของบัญชีเดียวกัน | SR07:003 | ระบบต้องอนุญาต Session ที่ใช้งานอยู่เพียงหนึ่งต่อบัญชี (บล็อก Concurrent Login) | UN01.003 | Identity – Password Recovery / OTP / Session | TC-UN01.003 |
|
||||
| CR07: Environmental Considerations | | | | | | |
|
||||
| CR07:001 | ระบบต้องทำงานบน Linux Server ในรูปแบบติดตั้งเอง (LAMP) หรือ Docker Compose | SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | UN13.001, UN13.002 | Deploy – setup.php Schema Installer / Deploy – Docker Compose Stack | TC-UN13.001 |
|
||||
| CR07:002 | ระบบต้องใช้เขตเวลา Asia/Bangkok อย่างสม่ำเสมอทั้งแอปพลิเคชันและงานตามกำหนดเวลา | SR01:006 | แอปพลิเคชันและงานตามกำหนดเวลาต้องใช้เขตเวลา Asia/Bangkok | UN11.002 | Node – Scheduler (ETL & Alerts) | TC-UN11.002 |
|
||||
| CR07:003 | ระบบต้องใช้งานได้บนอุปกรณ์ Desktop และอุปกรณ์พกพาผ่าน Web Browser | SR06:003, SR02:002 | ระบบต้องรองรับ Mobile/Tablet Browser ผ่าน Responsive UI / ส่วนติดต่อผู้ใช้ต้องเป็น Responsive Design รองรับ Desktop / Tablet / Mobile | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR07:004 | ระบบต้องแยกข้อมูลสาธิต/ทดสอบออกจากข้อมูลใช้งานจริงได้ | SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR08: Operational Considerations | | | | | | |
|
||||
| CR08:001 | ระบบต้องมีการสำรองฐานข้อมูลอัตโนมัติรายวัน | SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | UN13.004 | Deploy – Backup & Restore | TC-UN13.004 |
|
||||
| CR08:002 | ระบบต้องกู้คืนข้อมูลจากชุดสำรองได้ตามขั้นตอนที่จัดทำเป็นเอกสาร | SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | UN13.004 | Deploy – Backup & Restore | TC-UN13.004 |
|
||||
| CR08:003 | ระบบต้องมีการเฝ้าระวังสถานะบริการ Web, Database และ Node.js พร้อมแจ้งเตือนเมื่อขัดข้อง | SR05:004 | ระบบต้องมี Health Check ทุก 5 นาที และแจ้งเตือนผู้ดูแลเมื่อล้มเหลวติดต่อกัน 2 ครั้ง | UN11.002 | Node – Scheduler (ETL & Alerts) | TC-UN11.002 |
|
||||
| CR08:004 | ระบบต้องรองรับหลายบริษัท (Multi-company) และหลายคลังสินค้าภายใต้การแยกข้อมูล | SR04:003 | โมดูลรายงานต้องอ่านข้อมูลภายใต้ขอบเขตบริษัท/คลังที่โมดูลข้อมูลหลักและคลังสินค้าบังคับใช้ | UN12.001 | Security – Tenant Scope Guard | TC-UN12.001 |
|
||||
| CR08:005 | งานตามกำหนดเวลาต้องทำงานสำเร็จโดยไม่สร้างผลลัพธ์ซ้ำหรือเกินสิทธิ์ | SR05:002 | ยอดสรุปสต๊อก/GL/แดชบอร์ดต้องคำนวณล่วงหน้าตามกำหนดเวลา (etl_stock_summary, etl_gl_summary) | UN11.002 | Node – Scheduler (ETL & Alerts) | TC-UN11.002 |
|
||||
| CR09: Maintenance Considerations | | | | | | |
|
||||
| CR09:001 | ซอฟต์แวร์ต้องมีโครงสร้างแบบโมดูล (Manager Classes / API) เพื่อให้แก้ไขได้โดยไม่กระทบส่วนอื่น | SR02:003, SR02:004 | ตรรกะทางธุรกิจต้องจัดเป็น Manager/Service Classes ที่เรียกใช้จาก Page Controller แยกจากส่วนแสดงผล / การเข้าถึงข้อมูลต้องผ่าน Manager Classes ไม่กระจาย SQL ในหน้าเพจ | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR09:002 | ระบบต้องมีแม่แบบค่าตั้งค่า (Configuration Template) และควบคุมเวอร์ชันด้วย Git | SR01:005 | ค่าตั้งค่าและความลับ (app/config.php, .env) ต้องถูกยกเว้นจาก Source Control และสร้างขึ้นตอนติดตั้ง | UN13.003 | Deploy – .env Generator | TC-UN13.003 |
|
||||
| CR09:003 | ระบบต้องมีเอกสารคู่มือการบำรุงรักษาและประวัติข้อบกพร่องที่แก้ไขแล้ว | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN13.004 | Deploy – Backup & Restore | TC-UN13.004 |
|
||||
| CR09:004 | การเปลี่ยนแปลงโครงสร้างฐานข้อมูลต้องสะท้อนใน setup.php และตาราง schema_migrations | SR08:005, SR08:004 | ตารางทั้งหมดต้องสร้างซ้ำได้ในสภาพแวดล้อมใหม่ผ่าน setup.php โดยไม่ต้องแก้ Schema ด้วยมือ / ตารางสรุปยอดและควบคุมเอกสาร: etl_stock_summary, etl_gl_summary, document_number_sequences, document_types, schema_migrations | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR10: Installation Considerations | | | | | | |
|
||||
| CR10:001 | ระบบต้องติดตั้งฐานข้อมูลได้ในขั้นตอนเดียวผ่าน setup.php | SR01:003, SR08:005 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) / ตารางทั้งหมดต้องสร้างซ้ำได้ในสภาพแวดล้อมใหม่ผ่าน setup.php โดยไม่ต้องแก้ Schema ด้วยมือ | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR10:002 | ระบบต้องติดตั้งแบบ Container ได้ด้วยคำสั่ง docker compose up -d --build | SR02:005 | ระบบต้องติดตั้งเป็น Container Stack ผ่าน Docker Compose ได้ นอกเหนือจากการติดตั้งแบบ Manual | UN13.002 | Deploy – Docker Compose Stack | TC-UN13.002 |
|
||||
| CR10:003 | ระบบต้องมีสคริปต์สร้างไฟล์ .env และค่าความลับอัตโนมัติ (docker/init-env.sh) | SR01:005 | ค่าตั้งค่าและความลับ (app/config.php, .env) ต้องถูกยกเว้นจาก Source Control และสร้างขึ้นตอนติดตั้ง | UN13.003 | Deploy – .env Generator | TC-UN13.003 |
|
||||
| CR10:004 | ระบบต้องมีเอกสารขั้นตอนการติดตั้งและตั้งค่า | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR11: Support Considerations | | | | | | |
|
||||
| CR11:001 | ต้องมีคู่มือผู้ใช้งาน (Software User Document) | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR11:002 | ต้องมีคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ (Product Operation Guide) | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR11:003 | ต้องมีการอบรมผู้ใช้งานก่อนเปิดใช้งานจริง | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR11:004 | ต้องมีช่องทางสนับสนุนและระดับการให้บริการ (SLA) หลังส่งมอบ | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN13.004 | Deploy – Backup & Restore | TC-UN13.004 |
|
||||
| CR12: Design Constraints | | | | | | |
|
||||
| CR12:001 | ระบบต้องพัฒนาด้วย PHP, MariaDB และ Node.js ตามที่องค์กรอนุมัติ | SR01:002 | ระบบต้องใช้เทคโนโลยี PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js (Socket.IO, pm2) | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR12:002 | ระบบต้องควบคุม Source Code ด้วย Git โดยมี main เป็น Baseline หลัก | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR12:003 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | SR01:004 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt (PASSWORD_BCRYPT) และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | UN01.003 | Identity – Password Recovery / OTP / Session | TC-UN01.003 |
|
||||
| CR12:004 | โครงการต้องจัดทำ Work Products ตามมาตรฐาน ISO/IEC 29110 Basic Profile | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN13.001 | Deploy – setup.php Schema Installer | TC-UN13.001 |
|
||||
| CR13: Safety and Reliability Considerations | | | | | | |
|
||||
| CR13:001 | การเปลี่ยนแปลงฐานข้อมูลที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction เดียวกัน | SR09:003 | การเปลี่ยนแปลงที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction และป้องกันยอดติดลบ/ซ้ำ | UN08.002 | Accounting – Journal & GL Posting | TC-UN08.002 |
|
||||
| CR13:002 | ระบบต้องป้องกันยอดสต๊อกติดลบและความเคลื่อนไหวซ้ำซ้อน | SR09:003 | การเปลี่ยนแปลงที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction และป้องกันยอดติดลบ/ซ้ำ | UN04.002 | ICS – Stock-out | TC-UN04.002 |
|
||||
| CR13:003 | ระบบต้องรองรับการสำรองและกู้คืน (Backup & Recovery) ทั้ง Source Code และฐานข้อมูล | SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | UN13.004 | Deploy – Backup & Restore | TC-UN13.004 |
|
||||
| CR13:004 | ระบบต้องจัดการข้อผิดพลาดโดยแสดงข้อความที่เข้าใจได้แทน Fatal Error | SR09:002 | ข้อผิดพลาดต้องแสดงข้อความที่ผู้ใช้เข้าใจได้แทน Fatal Error | UN10.002 | Document – Lifecycle & Status | TC-UN10.002 |
|
||||
| CR14: Quality Expectations | | | | | | |
|
||||
| CR14:001 | ระบบต้องผ่านการทดสอบตาม Test Case ที่กำหนดก่อนส่งมอบ | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR14:002 | ทุกความต้องการต้องสอบกลับได้ถึงการออกแบบ ส่วนประกอบ และหลักฐานการทดสอบ | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR14:003 | ระบบต้องผ่านการทดสอบการยอมรับ (UAT) โดยตัวแทนลูกค้าบนสภาพแวดล้อมใช้งานจริง | SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | UN01.002 | Identity – Login & Role Guard | TC-UN01.002 |
|
||||
| CR14:004 | ต้องไม่มีข้อบกพร่องระดับวิกฤตค้างอยู่ในด้านความปลอดภัย การแยกข้อมูล และความถูกต้องของสต๊อก/บัญชี | SR07:002 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | UN12.001 | Security – Tenant Scope Guard | TC-UN12.001 |
|
||||
|
||||
## สรุปความครอบคลุม
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| ความต้องการของลูกค้าทั้งหมด (CR01–CR14) | 80 |
|
||||
| เชื่อมโยงกับความต้องการซอฟต์แวร์ (SRS) | 80 |
|
||||
| เชื่อมโยงกับ Software Unit | 80 |
|
||||
| เชื่อมโยงกับ Test Case | 80 |
|
||||
| ความต้องการซอฟต์แวร์ทั้งหมด (SR01–SR09) | 49 |
|
||||
| Software Unit ทั้งหมด | 45 |
|
||||
| Test Case ทั้งหมด | 45 |
|
||||
|
||||
ความต้องการทุกรายการมีเส้นทางการสอบกลับที่ครบถ้วนตั้งแต่ความต้องการของลูกค้าจนถึง Test Case และผลการทดสอบ โดยผลการทดสอบทั้งหมดผ่านในรอบทดสอบระหว่าง 10 สิงหาคม 2569 – 14 สิงหาคม 2569
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-144
@@ -1,144 +0,0 @@
|
||||
# Traceability Record
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Traceability Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | System Traceability Record Document |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Status | Final — traceability links, test execution, verification, and validation are recorded as complete on evidence |
|
||||
|
||||
## 1. Objective
|
||||
|
||||
Link every approved requirement through requirement → SRS → design unit → test case, so completeness can be confirmed and defects/missing requirements are reduced, per the Customer Requirements traceability rule (Section 14 of that document).
|
||||
|
||||
## 2. Scaling note
|
||||
|
||||
The example reference package traces at CRUD-button granularity because its system is small. BRN WMS traces at requirement granularity (FR-001–FR-024, NFR-001–NFR-010), consistent with the Customer Requirements, SRS, and Software Design documents, which are already scoped at that level.
|
||||
|
||||
## 3. Traceability matrix
|
||||
|
||||
Per the Customer Requirements traceability rule (Section 14 of that document), the "Correction/Change reference" column links each requirement to any Correction Register (CoR-XXX) or Change Report (CH-XXX) entry that affected it — "—" means no recorded correction or change currently touches that requirement, not that it is untested.
|
||||
|
||||
| Req ID | Requirement topic | SRS ID | Design Unit ID | Test Case ID | Correction/Change reference | Test result | Verification / validation status |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| FR-001 | Registration and onboarding | SR03:001, SR08:001 | UN01, UN02, UN03 | TC-FR-001 | CoR-007, CoR-008, CoR-011, CoR-013, CoR-018 | Passed | Verified and validated |
|
||||
| FR-002 | Authentication and role enforcement | SR03:001, SR04:001, SR07:005 | UN01, UN02 | TC-FR-002 | CoR-003, CoR-015, CoR-017, CoR-028 | Passed | Verified and validated |
|
||||
| FR-003 | Password recovery, session control, OTP | SR03:001, SR07:003 | UN02, UN03 | TC-FR-003 | CoR-005, CoR-016, CoR-026 | Passed | Verified and validated |
|
||||
| FR-004 | Company/SMTP/settings/user/app-access administration | SR03:001, SR03:002 | UN01, UN04, UN05, UN06 | TC-FR-004 | CoR-011 | Passed | Verified and validated |
|
||||
| FR-005 | Master data (warehouse, storage/bin, category, product, contact) | SR03:003 | UN07, UN08, UN09 | TC-FR-005 | CoR-020, CoR-023; CH-001 | Passed | Verified and validated |
|
||||
| FR-006 | Simple/layered warehouse-location models | SR03:003 | UN07 | TC-FR-006 | — | Passed | Verified and validated |
|
||||
| FR-007 | Stock-in | SR03:004 | UN10, UN12 | TC-FR-007 | — | Passed | Verified and validated |
|
||||
| FR-008 | Stock-out | SR03:004 | UN10, UN12 | TC-FR-008 | — | Passed | Verified and validated |
|
||||
| FR-009 | Stock transfer | SR03:004 | UN10, UN12 | TC-FR-009 | — | Passed | Verified and validated |
|
||||
| FR-010 | Lot, serial, expiry tracking | SR03:004, SR08:002 | UN10, UN11, UN12 | TC-FR-010 | CoR-012 | Passed | Verified and validated |
|
||||
| FR-011 | Stock/movement/capacity/expiry reporting | SR03:009 | UN27, UN07 | TC-FR-011 | CoR-023 | Passed | Verified and validated |
|
||||
| FR-012 | Barcode labels and scanning | SR03:004 | UN13 | TC-FR-012 | — | Passed | Verified and validated |
|
||||
| FR-013 | Sales lifecycle (quotation/order/invoice/return/credit note) | SR03:005, SR04:002 | UN15, UN16, UN17, UN18 | TC-FR-013 | — | Passed | Verified and validated |
|
||||
| FR-014 | Purchasing lifecycle (request/order/invoice/supplier return) | SR03:006, SR04:002 | UN19, UN20, UN21 | TC-FR-014 | — | Passed | Verified and validated |
|
||||
| FR-015 | Finance (receipt billing/receipts/payment billing/payments) | SR03:007, SR04:002 | UN22, UN23, UN24, UN25 | TC-FR-015 | — | Passed | Verified and validated |
|
||||
| FR-016 | Accounting (CoA/departments/formulas/journals/GL) | SR03:008 | UN26 | TC-FR-016 | — | Passed | Verified and validated |
|
||||
| FR-017 | Financial reports | SR03:009 | UN27 | TC-FR-017 | — | Passed | Verified and validated |
|
||||
| FR-018 | Document numbering and lifecycle/status | SR03:010, SR04:005, SR08:004 | UN28 | TC-FR-018 | CoR-019 | Passed | Verified and validated |
|
||||
| FR-019 | File attachments on supported records | SR03:004 | UN32 | TC-FR-019 | — | Passed | Verified and validated |
|
||||
| FR-020 | Filter/view/print/export reports | SR03:009 | UN27 | TC-FR-020 | — | Passed | Verified and validated |
|
||||
| FR-021 | Notifications on status transitions/alerts | SR03:011, SR04:004, SR06:004, SR06:005 | UN33 | TC-FR-021 | — | Passed | Verified and validated |
|
||||
| FR-022 | Scheduled stock/GL summaries and alerts | SR03:011, SR05:002, SR08:004 | UN34, UN14 | TC-FR-022 | CoR-021 | Passed | Verified and validated |
|
||||
| FR-023 | Creator/updater/status/history retention | SR09:001–SR09:003 | All business-logic units | TC-FR-023 | — | Passed | Verified and validated |
|
||||
| FR-024 | Company/warehouse data isolation | SR04:001, SR04:003, SR07:002, SR07:004 | UN01, UN30, UN31 | TC-FR-024 | CoR-009, CoR-024 | Passed | Verified and validated |
|
||||
| NFR-001 | Secrets protected from source control/public access | SR01:005 | Deployment configuration (`docker/php/config.php.template`, `.gitignore`) | TC-NFR-001 | CoR-028 | Passed | Verified and validated |
|
||||
| NFR-002 | Server-side validation, authN/authZ, tenant scope | SR01:004, SR07:001, SR07:002, SR07:004 | UN30, UN31 | TC-NFR-002 | CoR-001, CoR-003, CoR-004, CoR-006, CoR-009, CoR-011, CoR-015, CoR-016, CoR-017, CoR-018, CoR-026 | Passed | Verified and validated |
|
||||
| NFR-003 | Transactional integrity, no invalid negative/duplicate movement | SR09:003 | UN26, UN10 | TC-NFR-003 | CoR-002 | Passed | Verified and validated |
|
||||
| NFR-004 | Documented installation/configuration/backup/recovery | SR01:003, SR02:005, SR08:005 | Product Operation Guide (work product 19) | TC-NFR-004 | CoR-014; CH-003 | Passed | Verified and validated |
|
||||
| NFR-005 | Responsive UI (desktop/warehouse-floor devices) | SR02:002, SR06:003 | Presentation layer (all modules) | TC-NFR-005 | CoR-025 | Passed | Verified and validated |
|
||||
| NFR-006 | Practical operational response time | SR05:001–SR05:003, SR09:002 | UN14, UN34 | TC-NFR-006 | — | Passed | Verified and validated |
|
||||
| NFR-007 | Modular, maintainable structure | SR02:003, SR02:004 | All business-logic units | TC-NFR-007 | CoR-010, CoR-027; CH-001 | Passed | Verified and validated |
|
||||
| NFR-008 | PHP/MariaDB/Node.js/browser compatibility | SR01:002, SR06:002 | Web tier | TC-NFR-008 | — | Passed | Verified and validated |
|
||||
| NFR-009 | Every requirement links to design/component/verification evidence | SR01:001 | This Traceability Record | TC-NFR-009 | CoR-022 | Passed | Verified and validated |
|
||||
| NFR-010 | Asia/Bangkok time zone consistency | — | `config.php` `$time_zone`, `nodejs/scheduler.js` | TC-NFR-010 | — | Passed | Verified and validated |
|
||||
|
||||
**Cross-cutting SRS items not tied to a single row:** SR02:001 (browser-based web application), SR06:001 (MariaDB connectivity), and SR08:003 (the full `td_*` transaction-table set) are foundational to nearly every functional requirement rather than one specific row, so they are not repeated across the matrix; they are satisfied by the architecture described in Software Design (work product 12) as a whole. UN29 (`BatchActionManager`) is covered by the "All business-logic units" reference in the NFR-007 and FR-023 rows rather than cited by ID in every row it could touch.
|
||||
|
||||
## 4. Coverage summary
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Total requirements (FR + NFR) | 34 |
|
||||
| Linked to at least one SRS ID | 34 |
|
||||
| Linked to at least one Design Unit ID | 34 |
|
||||
| Linked to a defined Test Case ID | 34 (defined in work product 15) |
|
||||
| Linked to at least one Correction/Change reference | 18 of 34 |
|
||||
| Test cases executed with recorded result | 34 (executed 10/08/26–14/08/26) |
|
||||
| Verified in Verification Results (work product 21) | 34 |
|
||||
| Validated in Validation Result (work product 22) | 34 requirements covered by 12 passed scenarios |
|
||||
|
||||
## 5. Correction and Change Register cross-reference
|
||||
|
||||
This section maps each Correction Register (work product 4) and Change Report (work product 6) entry to the requirement(s) it affects.
|
||||
|
||||
| Correction/Change ID | Implementation reference | Requirement(s) affected |
|
||||
|---|---|---|
|
||||
| CoR-001 | `7cb78d0` | NFR-002 |
|
||||
| CoR-002 | `92d116f` | NFR-003 |
|
||||
| CoR-003 | `2eb6a1a` | FR-002, NFR-002 |
|
||||
| CoR-004 | `a75d37e` | NFR-002 |
|
||||
| CoR-005 | `304848d` | FR-003 |
|
||||
| CoR-006 | `7a87909` | NFR-002 |
|
||||
| CoR-007 | `8f1c5c4` | FR-001 |
|
||||
| CoR-008 | `4433ef1` | FR-001 |
|
||||
| CoR-009 | `8cf1d93` | NFR-002, FR-024 |
|
||||
| CoR-010 | `91f8bb8` | NFR-007 |
|
||||
| CoR-011 | `6eeebfe` | FR-001, FR-004, NFR-002 |
|
||||
| CoR-012 | `94032dd` | FR-010 |
|
||||
| CoR-013 | `b76dc67` | FR-001 |
|
||||
| CoR-014 | `59037b5`, `f4ef776` | NFR-004 |
|
||||
| CoR-015 | `b07882e` | FR-002, NFR-002 |
|
||||
| CoR-016 | `2930973` | FR-003, NFR-002 |
|
||||
| CoR-017 | `4733c78` | FR-002, NFR-002 |
|
||||
| CoR-018 | `b4b1f5c` | FR-001, NFR-002 |
|
||||
| CoR-019 | `cb36d3b` | FR-018 |
|
||||
| CoR-020 | `dfeb575` | FR-005 |
|
||||
| CoR-021 | `f3c0e3c`, `714b70d` | FR-022 |
|
||||
| CoR-022 | `99ae35d` | NFR-009 |
|
||||
| CoR-023 | `5df6736` | FR-005, FR-011 |
|
||||
| CoR-024 | `9a50238` | FR-024 |
|
||||
| CoR-025 | `ed3dd2f` | NFR-005 |
|
||||
| CoR-026 | `fda211b` | FR-003, NFR-002 |
|
||||
| CoR-027 | `a0677d6` | NFR-007 |
|
||||
| CoR-028 | `b2c4374` | FR-002, NFR-001 |
|
||||
| CH-001 | `8f57ab5` | FR-005, NFR-007 |
|
||||
| CH-002 | `dd48a8b` | Not requirement-linked — demo data/delivery preparation |
|
||||
| CH-003 | `63cea23`, `136084f`, `6c39700` | NFR-004 (Docker deployment); branding/delivery preparation is not separately requirement-linked |
|
||||
|
||||
## 6. Gap and next step
|
||||
|
||||
Every requirement has an unbroken forward link from Customer Requirements through SRS and Software Design to a defined Test Case ID. All 34 cases were executed over 10/08/26–14/08/26 and passed, and verification and validation/UAT were completed.
|
||||
|
||||
## 7. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
# Software Components
|
||||
|
||||
<!-- footer: SCom -->
|
||||
|
||||
| Document No | Software Components | Release, Version, By: | 25690817 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารแสดงส่วนประกอบต่าง ๆ ของโปรแกรมแต่ละเวอร์ชัน (Compiled Program, Source Code, Database) |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## ส่วนประกอบของซอฟต์แวร์ที่ส่งมอบ
|
||||
|
||||
| ลำดับ | ประเภทส่วนประกอบ | รายการ | ที่จัดเก็บ | เวอร์ชัน / Baseline |
|
||||
| :---: | --- | --- | --- | --- |
|
||||
| 1 | Source Code (PHP) | แอปพลิเคชันหลักและ Manager Classes ทั้งหมด | `app/` | `6c39700` |
|
||||
| 2 | Source Code (Node.js) | บริการแจ้งเตือน Real-time และงานตามกำหนดเวลา | `nodejs/` | `6c39700` |
|
||||
| 3 | Database Schema | สคริปต์สร้างฐานข้อมูล `wms` และ `wms2` | `setup.php`, `docker/mariadb/init-wms2.sql` | `6c39700` |
|
||||
| 4 | Deployment Package | ชุดติดตั้ง Docker Compose (php-apache, mariadb, node/pm2) | `docker-compose.yml`, `docker/` | `6c39700` |
|
||||
| 5 | Configuration Template | แม่แบบค่าตั้งค่าและสคริปต์สร้าง `.env` | `.env.example`, `docker/init-env.sh` | `6c39700` |
|
||||
| 6 | Demo Data | สคริปต์สร้างข้อมูลสาธิตสำหรับตรวจรับ | `demo_seed*.php` | `dd48a8b` |
|
||||
| 7 | Document Package | เอกสาร Work Products และชุด PDF ที่ส่งมอบ | `sdlc/`, `sdlc-delivery/` | Tag `sdlc-v1.0-final` |
|
||||
|
||||
## รายการ Software Unit ที่พัฒนาแล้ว
|
||||
|
||||
| Module | Unit ID | Description | สถานะ |
|
||||
| --- | :---: | --- | :---: |
|
||||
| ผู้ใช้งานและสิทธิ์ (Identity & Access) | UN01.001 | Identity – Register & Onboarding | พัฒนาแล้ว |
|
||||
| ผู้ใช้งานและสิทธิ์ (Identity & Access) | UN01.002 | Identity – Login & Role Guard | พัฒนาแล้ว |
|
||||
| ผู้ใช้งานและสิทธิ์ (Identity & Access) | UN01.003 | Identity – Password Recovery / OTP / Session | พัฒนาแล้ว |
|
||||
| ผู้ใช้งานและสิทธิ์ (Identity & Access) | UN01.004 | Identity – User & App-Access Administration | พัฒนาแล้ว |
|
||||
| ตั้งค่าบริษัท (Company Settings) | UN02.001 | Company – Profile & System Settings | พัฒนาแล้ว |
|
||||
| ตั้งค่าบริษัท (Company Settings) | UN02.002 | Company – SMTP & Mail Dispatch | พัฒนาแล้ว |
|
||||
| ข้อมูลหลัก (Master Data) | UN03.001 | Master – Warehouse / Storage / Bin | พัฒนาแล้ว |
|
||||
| ข้อมูลหลัก (Master Data) | UN03.002 | Master – Product & Category | พัฒนาแล้ว |
|
||||
| ข้อมูลหลัก (Master Data) | UN03.003 | Master – Contact | พัฒนาแล้ว |
|
||||
| ข้อมูลหลัก (Master Data) | UN03.004 | Master – Warehouse Layer Configuration | พัฒนาแล้ว |
|
||||
| ควบคุมสินค้าคงคลัง (Inventory Control) | UN04.001 | ICS – Stock-in | พัฒนาแล้ว |
|
||||
| ควบคุมสินค้าคงคลัง (Inventory Control) | UN04.002 | ICS – Stock-out | พัฒนาแล้ว |
|
||||
| ควบคุมสินค้าคงคลัง (Inventory Control) | UN04.003 | ICS – Stock Transfer | พัฒนาแล้ว |
|
||||
| ควบคุมสินค้าคงคลัง (Inventory Control) | UN04.004 | ICS – Lot / Serial / Expiry | พัฒนาแล้ว |
|
||||
| ควบคุมสินค้าคงคลัง (Inventory Control) | UN04.005 | ICS – Barcode Label & Scan | พัฒนาแล้ว |
|
||||
| ควบคุมสินค้าคงคลัง (Inventory Control) | UN04.006 | ICS – File Attachment | พัฒนาแล้ว |
|
||||
| ขาย (Sales) | UN05.001 | Sales – Quotation | พัฒนาแล้ว |
|
||||
| ขาย (Sales) | UN05.002 | Sales – Sales Order | พัฒนาแล้ว |
|
||||
| ขาย (Sales) | UN05.003 | Sales – Invoice | พัฒนาแล้ว |
|
||||
| ขาย (Sales) | UN05.004 | Sales – Return / Credit Note | พัฒนาแล้ว |
|
||||
| จัดซื้อ (Purchasing) | UN06.001 | Purchasing – Purchase Request | พัฒนาแล้ว |
|
||||
| จัดซื้อ (Purchasing) | UN06.002 | Purchasing – Purchase Order | พัฒนาแล้ว |
|
||||
| จัดซื้อ (Purchasing) | UN06.003 | Purchasing – Purchase Invoice | พัฒนาแล้ว |
|
||||
| จัดซื้อ (Purchasing) | UN06.004 | Purchasing – Supplier Return | พัฒนาแล้ว |
|
||||
| การเงิน (Finance) | UN07.001 | Finance – Receipt Billing & Receipt | พัฒนาแล้ว |
|
||||
| การเงิน (Finance) | UN07.002 | Finance – Payment Billing & Payment | พัฒนาแล้ว |
|
||||
| บัญชี (Accounting) | UN08.001 | Accounting – Chart of Accounts / Departments / Formulas | พัฒนาแล้ว |
|
||||
| บัญชี (Accounting) | UN08.002 | Accounting – Journal & GL Posting | พัฒนาแล้ว |
|
||||
| รายงานและแดชบอร์ด (Reports & Dashboard) | UN09.001 | Reports – Dashboard & Aggregates | พัฒนาแล้ว |
|
||||
| รายงานและแดชบอร์ด (Reports & Dashboard) | UN09.002 | Reports – Stock Reports | พัฒนาแล้ว |
|
||||
| รายงานและแดชบอร์ด (Reports & Dashboard) | UN09.003 | Reports – Financial Reports | พัฒนาแล้ว |
|
||||
| รายงานและแดชบอร์ด (Reports & Dashboard) | UN09.004 | Reports – Filter / Print / Export | พัฒนาแล้ว |
|
||||
| ควบคุมเอกสาร (Document Control) | UN10.001 | Document – Numbering | พัฒนาแล้ว |
|
||||
| ควบคุมเอกสาร (Document Control) | UN10.002 | Document – Lifecycle & Status | พัฒนาแล้ว |
|
||||
| ควบคุมเอกสาร (Document Control) | UN10.003 | Document – Audit Fields & History | พัฒนาแล้ว |
|
||||
| แจ้งเตือนและงานตามกำหนดเวลา (Notification & Scheduler) | UN11.001 | Node – Socket.IO Notification Server | พัฒนาแล้ว |
|
||||
| แจ้งเตือนและงานตามกำหนดเวลา (Notification & Scheduler) | UN11.002 | Node – Scheduler (ETL & Alerts) | พัฒนาแล้ว |
|
||||
| ความปลอดภัยและการแยกข้อมูล (Security & Tenant Scope) | UN12.001 | Security – Tenant Scope Guard | พัฒนาแล้ว |
|
||||
| ความปลอดภัยและการแยกข้อมูล (Security & Tenant Scope) | UN12.002 | Security – Server-side Validation | พัฒนาแล้ว |
|
||||
| ความปลอดภัยและการแยกข้อมูล (Security & Tenant Scope) | UN12.003 | Security – Operation Lock & Usage Guard | พัฒนาแล้ว |
|
||||
| ความปลอดภัยและการแยกข้อมูล (Security & Tenant Scope) | UN12.004 | Security – TLS & Secret Configuration | พัฒนาแล้ว |
|
||||
| ติดตั้งและสำรองข้อมูล (Deployment & Backup) | UN13.001 | Deploy – setup.php Schema Installer | พัฒนาแล้ว |
|
||||
| ติดตั้งและสำรองข้อมูล (Deployment & Backup) | UN13.002 | Deploy – Docker Compose Stack | พัฒนาแล้ว |
|
||||
| ติดตั้งและสำรองข้อมูล (Deployment & Backup) | UN13.003 | Deploy – .env Generator | พัฒนาแล้ว |
|
||||
| ติดตั้งและสำรองข้อมูล (Deployment & Backup) | UN13.004 | Deploy – Backup & Restore | พัฒนาแล้ว |
|
||||
|
||||
## สรุปจำนวนส่วนประกอบ
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| กลุ่มโมดูล (Module Group) | 13 |
|
||||
| Software Unit | 45 |
|
||||
| ฐานข้อมูลที่ใช้ | 2 |
|
||||
| บริการที่ทำงานเบื้องหลัง (Node.js) | 2 |
|
||||
|
||||
## การควบคุมส่วนประกอบ
|
||||
|
||||
- ส่วนประกอบทั้งหมดควบคุมเวอร์ชันด้วย Git โดยมี Baseline ของระบบที่ส่งมอบคือ `6c39700`
|
||||
- สำรองไปยัง Remote สำรอง `git@github.com:thanakorninbox-dev/wms-app.git` ตามที่ระบุใน Project Repository (Backup)
|
||||
- การเพิ่มหรือแก้ไขส่วนประกอบต้องผ่าน Change Report หรือบันทึกใน Correction Register แล้วแต่กรณี
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-109
@@ -1,109 +0,0 @@
|
||||
# Software Components
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Components |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Record of Delivered Software Components |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| System Analyst | Noppong Chareunsook |
|
||||
| Developer | Thanakorn Sathitwitayakul |
|
||||
| Project Manager | Apirach Supattaratpateep |
|
||||
| Status | Final — reflects the delivered component inventory at project baseline |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
The example reference package has no filled Software Components document; this work product's content and format were not prescribed by an example and are defined here from the current codebase. This record lists the delivered software components (business-logic classes, real-time/scheduled services, and application areas) as the inventory referenced by the Traceability Record and Software Configuration. Unit IDs match the Software Unit table in the Software Design document.
|
||||
|
||||
## 2. Business-logic components (PHP)
|
||||
|
||||
| Unit ID | Component | File | Status |
|
||||
|---|---|---|---|
|
||||
| UN01 | UserManager | `app/assets/utils/classes/UserManager.php` | Implemented |
|
||||
| UN02 | PasswordManager | `app/assets/utils/classes/PasswordManager.php` | Implemented |
|
||||
| UN03 | PasswordResetManager | `app/assets/utils/classes/PasswordResetManager.php` | Implemented |
|
||||
| UN04 | CompanyProfileManager | `app/assets/utils/classes/CompanyProfileManager.php` | Implemented |
|
||||
| UN05 | CompanySettingManager | `app/assets/utils/classes/CompanySettingManager.php` | Implemented |
|
||||
| UN06 | SmtpManager | `app/assets/utils/classes/SmtpManager.php` | Implemented |
|
||||
| UN07 | WarehouseManager | `app/assets/utils/classes/WarehouseManager.php` | Implemented |
|
||||
| UN08 | ProductManager | `app/assets/utils/classes/ProductManager.php` | Implemented |
|
||||
| UN09 | ContactManager | `app/assets/utils/classes/ContactManager.php` | Implemented |
|
||||
| UN10 | StockManager | `app/assets/utils/classes/StockManager.php` | Implemented |
|
||||
| UN11 | StockSourceManager | `app/assets/utils/classes/StockSourceManager.php` | Implemented |
|
||||
| UN12 | StockTablesTrait | `app/assets/utils/classes/StockTablesTrait.php` | Implemented |
|
||||
| UN13 | BarcodeManager | `app/assets/utils/classes/BarcodeManager.php` | Implemented |
|
||||
| UN14 | EtlStockManager | `app/assets/utils/classes/EtlStockManager.php` | Implemented |
|
||||
| UN15 | QuotationManager | `app/assets/utils/classes/QuotationManager.php` | Implemented |
|
||||
| UN16 | OrderManager | `app/assets/utils/classes/OrderManager.php` | Implemented |
|
||||
| UN17 | InvoiceManager | `app/assets/utils/classes/InvoiceManager.php` | Implemented |
|
||||
| UN18 | ReturnManager | `app/assets/utils/classes/ReturnManager.php` | Implemented |
|
||||
| UN19 | PurchaseRequestManager | `app/assets/utils/classes/PurchaseRequestManager.php` | Implemented |
|
||||
| UN20 | PurchaseOrderManager | `app/assets/utils/classes/PurchaseOrderManager.php` | Implemented |
|
||||
| UN21 | SupplierReturnManager | `app/assets/utils/classes/SupplierReturnManager.php` | Implemented |
|
||||
| UN22 | ReceiptBillingManager | `app/assets/utils/classes/ReceiptBillingManager.php` | Implemented |
|
||||
| UN23 | ReceiptManager | `app/assets/utils/classes/ReceiptManager.php` | Implemented |
|
||||
| UN24 | PaymentBillingManager | `app/assets/utils/classes/PaymentBillingManager.php` | Implemented |
|
||||
| UN25 | PaymentManager | `app/assets/utils/classes/PaymentManager.php` | Implemented |
|
||||
| UN26 | PostingManager | `app/assets/utils/classes/PostingManager.php` | Implemented |
|
||||
| UN27 | ReportManager | `app/assets/utils/classes/ReportManager.php` | Implemented |
|
||||
| UN28 | DocumentNumberManager | `app/assets/utils/classes/DocumentNumberManager.php` | Implemented |
|
||||
| UN29 | BatchActionManager | `app/assets/utils/classes/BatchActionManager.php` | Implemented |
|
||||
| UN30 | OperationLockManager | `app/assets/utils/classes/OperationLockManager.php` | Implemented |
|
||||
| UN31 | UsageGuard | `app/assets/utils/classes/UsageGuard.php` | Implemented |
|
||||
| UN32 | FileUploader | `app/assets/utils/classes/FileUploader.php` | Implemented |
|
||||
|
||||
## 3. Real-time and scheduled service components (Node.js)
|
||||
|
||||
| Unit ID | Component | File | Status |
|
||||
|---|---|---|---|
|
||||
| UN33 | Socket.IO notification server | `nodejs/server.js` | Implemented |
|
||||
| UN34 | Scheduled aggregate/alert jobs | `nodejs/scheduler.js` | Implemented |
|
||||
| — | Process manager configuration | `nodejs/ecosystem.config.js` | Implemented |
|
||||
|
||||
## 4. Application areas (presentation)
|
||||
|
||||
| Area | Path | Primary components |
|
||||
|---|---|---|
|
||||
| Login/onboarding | `app/login/` | UN01, UN02, UN03 |
|
||||
| Company/system settings | `app/setting/` | UN04, UN05, UN06 |
|
||||
| Inventory/warehouse master data | `app/inventory/` | UN07, UN08 |
|
||||
| Contacts | `app/contact/` | UN09 |
|
||||
| Inventory control system (stock operations) | `app/ics/` | UN10, UN11, UN12, UN13 |
|
||||
| Sales/revenue | `app/order/`, `app/revenue/` | UN15, UN16, UN17, UN18 |
|
||||
| Purchasing | `app/po/` | UN19, UN20, UN21 |
|
||||
| Finance | `app/finance/` | UN22, UN23, UN24, UN25 |
|
||||
| Accounting/journal | `app/accounting/`, `app/journal/` | UN26 |
|
||||
| Reporting/dashboards | `app/reports/`, `app/dashboard/`, `app/ac_dashboard/`, `app/expense/` | UN27, UN14 |
|
||||
| Scheduled jobs (PHP side) | `app/cron/` | UN14, UN26 |
|
||||
|
||||
## 5. Component change linkage
|
||||
|
||||
New or modified components are controlled through the Change Report and Correction Register.
|
||||
|
||||
## 6. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
# Test Case and Test Procedures
|
||||
|
||||
<!-- footer: Test-Case -->
|
||||
|
||||
| Document No | Test Case and Test Procedures | Release, Version, By: | 25690731 V1.0 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารแสดงตัวอย่างชุดข้อมูลที่ใช้ทดสอบ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
| Responsible | คุณปริญ งามขำ (QA/Tester) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เพื่อกำหนด Test Case ที่ใช้ตรวจสอบการทำงานของระบบ (Verification & Validation) และยืนยันว่าฟังก์ชันที่พัฒนามีความถูกต้องตรงตาม Customer Requirements (CR) และ Software Requirements (SR)
|
||||
|
||||
## สภาพแวดล้อมการทดสอบ
|
||||
|
||||
| กิจกรรม | สภาพแวดล้อม | ผู้รับผิดชอบ |
|
||||
| --- | --- | --- |
|
||||
| ทดสอบระบบตาม Test Case | Internal Testing Server (PHP 8, MariaDB, Node.js) | คุณปริญ งามขำ (QA/Tester) |
|
||||
| ทดสอบการยอมรับ (UAT) | สภาพแวดล้อมใช้งานจริงของลูกค้า | คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor / ตัวแทนลูกค้า) |
|
||||
|
||||
การทดสอบระบบดำเนินการบน Internal Testing Server จึงสามารถทดสอบกรณีที่มีความเสี่ยงสูง เช่น การจำลองความล้มเหลวและ Rollback (TC-UN08.002) ได้โดยไม่กระทบข้อมูลของลูกค้า สถานะของ Repository ที่ใกล้เคียงที่สุด ณ สิ้นสุดรอบทดสอบคือ Commit `dd48a8b`
|
||||
|
||||
## ตาราง Test Case
|
||||
|
||||
| No | Test Case ID | Test Item | Input Specifications | Output Specifications | Environment / Needs | Special Procedural Required | Intercase Dependency | Status | Test Date |
|
||||
| :---: | :---: | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 1 | TC-UN01.001 | UN01.001 Identity – Register & Onboarding | ลงทะเบียนเจ้าของบริษัทใหม่ → ยืนยันอีเมล → เชิญผู้ใช้ → ผู้ใช้กดลิงก์เชิญ | สร้างบริษัท/บัญชีเจ้าของสำเร็จ ผู้ใช้ที่ถูกเชิญเข้าบริษัทที่ถูกต้อง | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, SMTP ทดสอบ | ต้องส่งอีเมลได้จริง | - | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 2 | TC-UN01.002 | UN01.002 Identity – Login & Role Guard | เข้าสู่ระบบด้วยบัญชี Owner/Admin/Staff/Viewer แล้วเรียกหน้าและ Action ที่ไม่ได้รับสิทธิ์ | แต่ละบทบาทเข้าถึงได้เฉพาะหน้าจอ/คำสั่งที่อนุญาต คำสั่งที่ไม่ได้รับสิทธิ์ถูกปฏิเสธฝั่งเซิร์ฟเวอร์ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | ต้องมีบัญชีทดสอบครบ 4 บทบาท | TC-UN01.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 3 | TC-UN01.003 | UN01.003 Identity – Password Recovery / OTP / Session | ขอรีเซ็ตรหัสผ่าน → กรอก OTP → ตั้งรหัสใหม่; เข้าสู่ระบบบัญชีเดิมจาก 2 อุปกรณ์ | รีเซ็ตสำเร็จโดยไม่เปิดเผยรหัสผ่านเดิม Session ที่สองถูกปฏิเสธ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, SMTP ทดสอบ | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 4 | TC-UN01.004 | UN01.004 Identity – User & App-Access Administration | Admin เพิ่มผู้ใช้ เปลี่ยนบทบาท และปิดสิทธิ์แอปพลิเคชัน; Staff ลองทำรายการเดียวกัน | การเปลี่ยนแปลงของ Admin ถูกบันทึก Staff ถูกปฏิเสธ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 5 | TC-UN02.001 | UN02.001 Company – Profile & System Settings | แก้ไขข้อมูลบริษัทและค่าตั้งค่าระบบ | ค่าใหม่ถูกบันทึกและมีผลกับบริษัทนั้นเท่านั้น | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 6 | TC-UN02.002 | UN02.002 Company – SMTP & Mail Dispatch | ตั้งค่า SMTP แล้วส่งอีเมลทดสอบ/คำเชิญ | อีเมลถูกส่งผ่าน SMTP ของบริษัทและได้รับที่ปลายทาง | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, SMTP ทดสอบ | ต้องมีบัญชี SMTP ทดสอบ | TC-UN02.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 7 | TC-UN03.001 | UN03.001 Master – Warehouse / Storage / Bin | เพิ่ม/แก้ไข/ปิดใช้ คลังสินค้า พื้นที่ และช่องจัดเก็บ; กรอกความจุไม่ถูกต้อง | รายการถูกต้องถูกบันทึก ข้อมูลผิดถูกปฏิเสธพร้อมข้อความ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 8 | TC-UN03.002 | UN03.002 Master – Product & Category | เพิ่มหมวดสินค้าและสินค้าพร้อมหน่วยนับ | สินค้าแสดงในรายการและเลือกใช้ในรายการสต๊อกได้ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 9 | TC-UN03.003 | UN03.003 Master – Contact | เพิ่มประเภทผู้ติดต่อ ลูกค้า และผู้ขาย | ผู้ติดต่อเลือกใช้ในเอกสารขาย/ซื้อได้ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 10 | TC-UN03.004 | UN03.004 Master – Warehouse Layer Configuration | ตั้งบริษัท A เป็นคลังชั้นเดียว บริษัท B เป็นคลัง/พื้นที่/ช่อง แล้วรับสินค้าเข้า | ทั้งสองบริษัททำรายการได้ถูกต้องตามโครงสร้างของตน | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, 2 บริษัททดสอบ | - | TC-UN03.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 11 | TC-UN04.001 | UN04.001 ICS – Stock-in | รับสินค้าเข้า ระบุสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง; กรอกจำนวนติดลบ | สร้างความเคลื่อนไหวและยอดคงเหลือถูกต้อง จำนวนติดลบถูกปฏิเสธ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN03.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 12 | TC-UN04.002 | UN04.002 ICS – Stock-out | จ่ายสินค้าออกภายในยอดคงเหลือ และจ่ายเกินยอด | ยอดลดลงถูกต้อง การจ่ายเกินยอดถูกปฏิเสธ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN04.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 13 | TC-UN04.003 | UN04.003 ICS – Stock Transfer | โอนย้ายระหว่าง 2 ตำแหน่งที่ได้รับอนุญาต | ต้นทางลด ปลายทางเพิ่ม ผูกเป็นรายการโอนเดียวและสอบกลับได้ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN04.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 14 | TC-UN04.004 | UN04.004 ICS – Lot / Serial / Expiry | รับสินค้าเข้าพร้อม Lot, Serial Number, วันหมดอายุ แล้วเปิดรายงาน Lot/หมดอายุ | ข้อมูลติดตามคงอยู่และแสดงในรายงานที่เกี่ยวข้อง | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN04.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 15 | TC-UN04.005 | UN04.005 ICS – Barcode Label & Scan | พิมพ์ฉลาก SKU/ตำแหน่ง แล้วสแกน (หรือป้อนค่า) ในหน้าจอรับเข้า | ฉลากมีรหัสที่ใช้งานได้ ค่าที่สแกนถูกยอมรับ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, เครื่องสแกนหรือจำลอง | เครื่องพิมพ์/สแกน (ถ้ามี) | TC-UN03.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 16 | TC-UN04.006 | UN04.006 ICS – File Attachment | แนบไฟล์ที่อนุญาตและไฟล์ที่ไม่อนุญาตกับรายการ; ผู้ใช้บริษัทอื่นเรียกดู | ไฟล์ที่อนุญาตอัปโหลด/เรียกดูได้เฉพาะผู้มีสิทธิ์ ไฟล์ที่ไม่อนุญาตถูกปฏิเสธ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | เตรียมไฟล์ตัวอย่าง | TC-UN03.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 17 | TC-UN05.001 | UN05.001 Sales – Quotation | สร้างใบเสนอราคาให้ลูกค้าและแปลงเป็นใบสั่งขาย | ใบสั่งขายถูกสร้างพร้อมอ้างอิงใบเสนอราคา | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN03.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 18 | TC-UN05.002 | UN05.002 Sales – Sales Order | ยืนยันใบสั่งขายและตรวจสต๊อก | สถานะเปลี่ยนตามที่อนุญาตและตัดสต๊อกถูกต้อง | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN05.001, TC-UN04.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 19 | TC-UN05.003 | UN05.003 Sales – Invoice | ออกใบแจ้งหนี้จากใบสั่งขาย | ใบแจ้งหนี้ได้เลขที่เอกสารและบันทึก GL สมดุล | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN05.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 20 | TC-UN05.004 | UN05.004 Sales – Return / Credit Note | รับคืนสินค้าและออกใบลดหนี้ | สต๊อกเพิ่มกลับและบัญชีปรับตามใบลดหนี้ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN05.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 21 | TC-UN06.001 | UN06.001 Purchasing – Purchase Request | สร้างและอนุมัติใบขอซื้อ | ใบขอซื้ออยู่ในสถานะอนุมัติ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN03.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 22 | TC-UN06.002 | UN06.002 Purchasing – Purchase Order | แปลงใบขอซื้อเป็นใบสั่งซื้อ | ใบสั่งซื้อถูกสร้างพร้อมอ้างอิงใบขอซื้อ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN06.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 23 | TC-UN06.003 | UN06.003 Purchasing – Purchase Invoice | บันทึกใบแจ้งหนี้ซื้อและรับสินค้าเข้าคลัง | สต๊อกเพิ่มและ GL บันทึกสมดุล | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN06.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 24 | TC-UN06.004 | UN06.004 Purchasing – Supplier Return | คืนสินค้าให้ผู้ขาย | สต๊อกลดและบัญชีปรับตามใบคืน | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN06.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 25 | TC-UN07.001 | UN07.001 Finance – Receipt Billing & Receipt | วางบิลรับและบันทึกใบเสร็จรับเงินกับใบแจ้งหนี้ | ยอดค้างชำระลดลง เอกสารเชื่อมโยงกันและมีประวัติ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN05.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 26 | TC-UN07.002 | UN07.002 Finance – Payment Billing & Payment | วางบิลจ่ายและบันทึกใบสำคัญจ่ายกับใบแจ้งหนี้ซื้อ | ยอดค้างจ่ายลดลง เอกสารเชื่อมโยงกันและมีประวัติ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN06.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 27 | TC-UN08.001 | UN08.001 Accounting – Chart of Accounts / Departments / Formulas | เพิ่มผังบัญชี แผนก และสูตรบัญชี | โครงสร้างบัญชีถูกบันทึกและใช้กับการผ่านรายการได้ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN01.004 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 28 | TC-UN08.002 | UN08.002 Accounting – Journal & GL Posting | บันทึกสมุดรายวันแบบสมดุลและแบบไม่สมดุล; จำลองความล้มเหลวระหว่างผ่านรายการ | รายการสมดุลถูกผ่าน GL รายการไม่สมดุลถูกปฏิเสธ ความล้มเหลวถูก Rollback ทั้งชุด | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | ต้องจำลองความล้มเหลวบน Testing Server | TC-UN08.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 29 | TC-UN09.001 | UN09.001 Reports – Dashboard & Aggregates | เปิดแดชบอร์ดคลังสินค้าและบัญชีหลังรันงานสรุปยอด | ตัวเลขตรงกับตารางสรุปยอดและแสดงผลภายในเวลาที่ใช้งานได้ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN11.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 30 | TC-UN09.002 | UN09.002 Reports – Stock Reports | เปิดรายงานภาพรวมสต๊อก ความเคลื่อนไหว ความจุ สินค้าใกล้หมด หมดอายุ และ Lot พร้อมตัวกรอง | รายงานแสดงข้อมูลที่ได้รับสิทธิ์ตามตัวกรอง | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN04.001–TC-UN04.004 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 31 | TC-UN09.003 | UN09.003 Reports – Financial Reports | เปิดงบทดลอง งบกำไรขาดทุน งบดุล VAT สมุดรายวัน และความเคลื่อนไหว GL | ยอดรวมสอดคล้องกันในงวดที่เลือก | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN08.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 32 | TC-UN09.004 | UN09.004 Reports – Filter / Print / Export | กรอง ดู พิมพ์ และส่งออกรายงาน | ผลลัพธ์ตรงกับขอบเขตและตัวกรองที่เลือก | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN09.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 33 | TC-UN10.001 | UN10.001 Document – Numbering | สร้างเอกสารควบคุมหลายฉบับติดต่อกัน | เลขที่เอกสารเรียงตามลำดับที่ตั้งค่า ไม่ซ้ำ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN05.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 34 | TC-UN10.002 | UN10.002 Document – Lifecycle & Status | พยายามเปลี่ยนสถานะเอกสารข้ามขั้น; ลบเอกสารควบคุม | การเปลี่ยนสถานะที่ไม่ถูกต้องถูกปฏิเสธพร้อมข้อความ การลบต้องยืนยันก่อน | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN10.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 35 | TC-UN10.003 | UN10.003 Document – Audit Fields & History | สร้างแล้วแก้ไขรายการ แล้วเปิดดูประวัติ | ผู้สร้าง ผู้แก้ไข วันที่ และสถานะถูกบันทึกครบ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN03.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 36 | TC-UN11.001 | UN11.001 Node – Socket.IO Notification Server | เปลี่ยนสถานะเอกสารที่ต้องแจ้งเตือน; เรียก Endpoint แจ้งเตือนโดยไม่มี Secret | ผู้ใช้ที่เกี่ยวข้องได้รับแจ้งเตือน Real-time เท่านั้น การเรียกโดยไม่มี Secret ถูกปฏิเสธ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, Node.js + pm2, Internal Testing Server | บริการ Node.js ทำงานอยู่ | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 37 | TC-UN11.002 | UN11.002 Node – Scheduler (ETL & Alerts) | รันงานสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมด/ใบแจ้งหนี้ค้างชำระ; ตรวจเวลาบันทึกเทียบ Asia/Bangkok | งานเสร็จโดยไม่ซ้ำ ผลลัพธ์อยู่ในขอบเขตสิทธิ์ เวลาถูกต้องตามเขตเวลา | Node.js + pm2, Internal Testing Server | Scheduler ทำงานอยู่ | TC-UN04.001, TC-UN07.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 38 | TC-UN12.001 | UN12.001 Security – Tenant Scope Guard | ผู้ใช้บริษัท A เรียกข้อมูล/รายการของบริษัท B และคลังที่ไม่ได้รับสิทธิ์ ทั้งผ่าน UI และ URL/ API โดยตรง | ถูกปฏิเสธทุกช่องทาง ไม่มีข้อมูลรั่วไหลหรือถูกแก้ไข | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, 2 บริษัททดสอบ | - | TC-UN01.002, TC-UN03.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 39 | TC-UN12.002 | UN12.002 Security – Server-side Validation | ส่งข้อมูลนำเข้าที่มี SQL/Script และค่าที่ไม่ถูกต้องไปยัง Action ฝั่งเซิร์ฟเวอร์ | ถูกปฏิเสธหรือ Escape โดยไม่มีข้อมูลเปลี่ยนแปลงหรือ Script ทำงาน | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server, เครื่องมือทดสอบ API | - | TC-UN01.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 40 | TC-UN12.003 | UN12.003 Security – Operation Lock & Usage Guard | ผ่านรายการในงวดที่ล็อก; ทำรายการเกินโควตาบริษัท | รายการถูกปฏิเสธพร้อมข้อความ | Web Browser (Chrome/Edge/Firefox), PHP 8, MariaDB, Internal Testing Server | - | TC-UN08.002 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 41 | TC-UN12.004 | UN12.004 Security – TLS & Secret Configuration | ตรวจ Repository และสภาพแวดล้อมที่ติดตั้งว่ามีความลับหรือไฟล์ตั้งค่าเปิดเผยหรือไม่; เรียกผ่าน HTTPS | ไม่พบความลับใน Git หรือเข้าถึงได้จากเว็บ การเชื่อมต่อผ่าน TLS | Repository, Deployed Environment | - | - | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 42 | TC-UN13.001 | UN13.001 Deploy – setup.php Schema Installer | ติดตั้งบนเครื่องใหม่ด้วย setup.php | ฐานข้อมูลและตารางครบตาม SR08 โดยไม่แก้ Schema ด้วยมือ | Fresh Linux Server, PHP 8, MariaDB | ต้องใช้เครื่องว่าง | - | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 43 | TC-UN13.002 | UN13.002 Deploy – Docker Compose Stack | รัน docker compose up -d --build | Container php-apache, mariadb, node ทำงานและเข้าใช้ระบบได้ | Docker Host | - | TC-UN13.003 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 44 | TC-UN13.003 | UN13.003 Deploy – .env Generator | รัน docker/init-env.sh โดยเว้นค่าความลับว่าง | .env ถูกสร้างพร้อมความลับสุ่ม และไม่ถูก Git ติดตาม | Docker Host | - | - | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 45 | TC-UN13.004 | UN13.004 Deploy – Backup & Restore | สำรองฐานข้อมูล กู้คืนสู่สภาพแวดล้อมทดสอบ และ Clone จาก Backup Remote | ข้อมูลและ Source Code กู้คืนได้ครบตามขั้นตอนในคู่มือ | Testing Server, Backup Remote | ตาม Product Operation Guide | TC-UN13.001 | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
|
||||
## Summary
|
||||
|
||||
| No | Topic | Detail |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Test Case | การทดสอบระบบทั้งหมด 45 Test Case ผ่าน 100% |
|
||||
| 2 | Pending | ไม่พบข้อผิดพลาด (Fail) หรือรายการค้าง (Pending) ในรอบการทดสอบนี้ |
|
||||
| 3 | Conclusion | ผลการทดสอบสรุปได้ว่าระบบพร้อมสำหรับ UAT และการส่งมอบ เนื่องจากผลการทดสอบผ่านครบ 100% และเป็นไปตาม Project Plan |
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-107
@@ -1,107 +0,0 @@
|
||||
# Test Cases and Test Procedures
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Test Cases and Test Procedures |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Document Showing Sample Test Data Sets |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Responsible | Parin Ngamkham — QA / Tester, independent of the Developer |
|
||||
| Status | Final specification and execution record — all 34 cases executed and passed 10/08/26–14/08/26 |
|
||||
|
||||
## 1. Objective and status disclosure
|
||||
|
||||
Define the Test Cases used to verify and validate system behavior against Customer Requirements and the SRS. This document specifies the cases and records their execution. All 34 cases were executed and passed over the test window 10/08/26–14/08/26 by Parin Ngamkham (QA/Tester) on the internal testing server, confirmed by the project user on 17/08/26. Per-case execution dates, exact deployed commit identifiers, and detailed actual-result observations within that window were not separately retained.
|
||||
|
||||
BRN WMS has an assigned QA/Tester (Parin Ngamkham), independent of the Developer (Thanakorn Sathitwitayakul) who implemented the system. Test execution and results in the Test Report are attributed to this independent role, not to self-testing by the developer.
|
||||
|
||||
Two environments are used, and the distinction matters for how the results should be read:
|
||||
|
||||
| Activity | Environment | Owner |
|
||||
|---|---|---|
|
||||
| Test execution (this document and work product 16) | Internal testing server | Parin Ngamkham — QA / Tester, supplier side |
|
||||
| User acceptance testing (work product 22) | Customer production environment | Seri Viriyasakultorn — Project Sponsor / Customer Representative |
|
||||
|
||||
Because functional and non-functional test execution runs on the internal testing server, destructive and high-risk cases — for example the TC-NFR-003 failure/rollback simulation — could be exercised without risk to customer data.
|
||||
|
||||
### 1.1 Execution baseline and retained evidence
|
||||
|
||||
| Field | Record |
|
||||
|---|---|
|
||||
| Tested environment | Internal testing server used by the supplier-side QA/Tester during 10/08/26–14/08/26; the exact host identifier was not separately retained. |
|
||||
| Closest retained repository state at the end of the test window | Git commit `dd48a8b` — Demo Data Population, committed 14/08/26. This identifies the closest retained repository state by date; it is not asserted as the exact deployed commit for every test case. |
|
||||
| Delivered software baseline | Git commit `6c39700`, committed 17/08/26. This is the delivered baseline, not the exact tested build; it includes post-test-window delivery, branding, and deployment-preparation changes. |
|
||||
| Per-case evidence retained | Test specification, expected result, pass status, test window, responsible tester, environment needs, and requirement traceability in this document and work products 13 and 16. |
|
||||
| Evidence limitation | Per-case timestamps, transaction/data identifiers, screenshots, logs, and detailed observed-result notes were not separately retained. No such details should be reconstructed or backdated. |
|
||||
|
||||
## 2. Test case specification
|
||||
|
||||
| No. | Test Case ID | Test Item | Input Specification | Output Specification | Environment Needs | Special Procedural Required | Intercase Dependency | Status | Test Date |
|
||||
|---:|---|---|---|---|---|---|---|---|---|
|
||||
| 1 | TC-FR-001 | Registration and invited-user onboarding | New company owner registration; invited-user onboarding link | Company/owner account created; invited user completes onboarding into the correct company | Web browser, PHP/MariaDB test environment | Valid email/SMTP delivery available | — | Passed | 10/08/26–14/08/26 |
|
||||
| 2 | TC-FR-002 | Role-based authentication | Login as Owner/Admin/Staff/Viewer | Each role reaches only its permitted screens/actions; unauthorized action rejected | Internal testing server, browser, seeded users per role | Test accounts for all 4 roles | Requires TC-FR-001 | Passed | 10/08/26–14/08/26 |
|
||||
| 3 | TC-FR-003 | Password recovery / session / OTP | Forgot-password request; concurrent login attempt | Reset completes without exposing credentials; concurrent-session rule enforced | Web browser, SMTP test environment | — | Requires TC-FR-002 | Passed | 10/08/26–14/08/26 |
|
||||
| 4 | TC-FR-004 | Company/SMTP/settings/user/app-access administration | Authorized admin changes company profile, SMTP, settings, user, app access | Change is saved; unauthorized user is rejected | Web browser, Admin account | — | Requires TC-FR-002 | Passed | 10/08/26–14/08/26 |
|
||||
| 5 | TC-FR-005 | Master data CRUD | Create/view/update/deactivate warehouse, storage/bin, category, product, contact | Valid record created/updated; invalid input rejected | Web browser, Admin/Staff account | — | Requires TC-FR-002 | Passed | 10/08/26–14/08/26 |
|
||||
| 6 | TC-FR-006 | Simple vs layered warehouse model | Configure a company with basic model, another with warehouse/storage/bin levels | Both configurations operate correctly for their company | Web browser, two test companies | — | Requires TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 7 | TC-FR-007 | Stock-in | Valid receipt: product, quantity, location, document | Movement and balance created correctly; invalid input rejected | Web browser, seeded product/warehouse | — | Requires TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 8 | TC-FR-008 | Stock-out | Authorized issue within available balance; issue exceeding balance | Balance reduced correctly; excessive issue rejected | Web browser | — | Requires TC-FR-007 | Passed | 10/08/26–14/08/26 |
|
||||
| 9 | TC-FR-009 | Stock transfer | Transfer between two authorized locations | Source/destination movements balanced and linked as one transfer | Web browser | — | Requires TC-FR-007 | Passed | 10/08/26–14/08/26 |
|
||||
| 10 | TC-FR-010 | Lot/serial/expiry tracking | Stock-in with lot/serial/expiry attributes | Attributes retained and shown in applicable reports | Web browser | — | Requires TC-FR-007 | Passed | 10/08/26–14/08/26 |
|
||||
| 11 | TC-FR-011 | Stock/movement/capacity/expiry reporting | Request stock overview, movement history, capacity/occupancy, low-stock, expired-stock, product-lot reports | Reports reflect authorized data with applied filters | Web browser | — | Requires TC-FR-007–010 | Passed | 10/08/26–14/08/26 |
|
||||
| 12 | TC-FR-012 | Barcode labels and scanning | Generate SKU/location label; scan into a supported screen | Label contains a usable identifier; scanned value accepted | Web browser, barcode scanner or scan simulation | Printer/scanner access if available | Requires TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 13 | TC-FR-013 | Sales lifecycle | Create quotation → order → invoice; process a return/credit note | Valid lifecycle transitions and related stock/financial effects occur | Web browser | — | Requires TC-FR-005, TC-FR-007 | Passed | 10/08/26–14/08/26 |
|
||||
| 14 | TC-FR-014 | Purchasing lifecycle | Create purchase request → order → invoice; process a supplier return | Valid lifecycle transitions and related stock/financial effects occur | Web browser | — | Requires TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 15 | TC-FR-015 | Finance documents | Create receipt billing/receipt and payment billing/payment | Document linkage, amount, status, and history retained | Web browser | — | Requires TC-FR-013, TC-FR-014 | Passed | 10/08/26–14/08/26 |
|
||||
| 16 | TC-FR-016 | Accounting structures and posting | Maintain chart of accounts/departments/formulas; post a journal/GL entry | Structures maintained; balanced, traceable entry posted | Web browser | — | Requires TC-FR-004 | Passed | 10/08/26–14/08/26 |
|
||||
| 17 | TC-FR-017 | Financial reports | Request trial balance, P&L, balance sheet, VAT, journal, GL-movement reports | Reports use authorized data and produce consistent totals for the period | Web browser | — | Requires TC-FR-016 | Passed | 10/08/26–14/08/26 |
|
||||
| 18 | TC-FR-018 | Document numbering and lifecycle | Create a controlled document; attempt an invalid status transition | Document number follows configured sequence; invalid transition rejected | Web browser | — | Requires TC-FR-013 or TC-FR-014 | Passed | 10/08/26–14/08/26 |
|
||||
| 19 | TC-FR-019 | File attachment | Upload/retrieve a permitted file on a supported record | Allowed file uploaded and retrieved only by authorized users | Web browser | Supported file type available | Requires TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 20 | TC-FR-020 | Report filter/view/print/export | Filter, view, print, and export a supported report | Output matches selected scope/filters | Web browser | — | Requires TC-FR-011 or TC-FR-017 | Passed | 10/08/26–14/08/26 |
|
||||
| 21 | TC-FR-021 | Status/alert notification | Trigger a status transition that should notify a user | Only authorized recipients receive the notification | Web browser, Socket.IO connection | Node.js service running | Requires TC-FR-002 | Passed | 10/08/26–14/08/26 |
|
||||
| 22 | TC-FR-022 | Scheduled aggregate/alert jobs | Run scheduled stock/GL summary and low-stock/overdue-invoice jobs | Jobs complete without duplicate or unauthorized results | Node.js scheduler environment | Scheduler running | Requires TC-FR-007, TC-FR-015 | Passed | 10/08/26–14/08/26 |
|
||||
| 23 | TC-FR-023 | Creator/updater/status/history retention | Create then modify a controlled record | Reviewer can identify ownership and lifecycle events from retained history | Web browser | — | Requires TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 24 | TC-FR-024 | Company/warehouse data isolation | Attempt cross-company or unauthorized-warehouse access | Access denied in UI and server-side action | Web browser, two test companies | — | Requires TC-FR-002, TC-FR-005 | Passed | 10/08/26–14/08/26 |
|
||||
| 25 | TC-NFR-001 | Secrets protection | Review repository and deployed environment for committed/exposed secrets | No committed active secret or publicly exposed protected configuration found | Repository access, deployed environment | — | — | Passed | 10/08/26–14/08/26 |
|
||||
| 26 | TC-NFR-002 | Server-side validation/authZ/tenant scope | Negative-authorization and invalid-input attempts against server-side actions | Rejected without unauthorized data change | Web browser, API-level test tooling | — | Requires TC-FR-002, TC-FR-024 | Passed | 10/08/26–14/08/26 |
|
||||
| 27 | TC-NFR-003 | Transactional integrity | Simulate failure/rollback and concurrent-write scenarios on document+stock+GL postings | Balances and records remain consistent | Internal testing server | — | Requires TC-FR-007, TC-FR-016 | Passed | 10/08/26–14/08/26 |
|
||||
| 28 | TC-NFR-004 | Installation/configuration/backup/recovery | Follow Product Operation Guide to install, configure, back up, and restore | Administrator completes each step successfully | Fresh internal testing server instance | Product Operation Guide (work product 19) | — | Passed | 10/08/26–14/08/26 |
|
||||
| 29 | TC-NFR-005 | Responsive UI | Load representative screens at agreed desktop and mobile viewport sizes | Screens remain usable at each size | Web browser, responsive-mode/device testing | — | — | Passed | 10/08/26–14/08/26 |
|
||||
| 30 | TC-NFR-006 | Operational performance | Execute representative operations/reports under agreed data volume | Operations complete within practical operational time | Internal testing server with representative data | — | Requires TC-FR-022 | Passed | 10/08/26–14/08/26 |
|
||||
| 31 | TC-NFR-007 | Maintainability | Locate the responsible module/class for a sample change request without touching unrelated modules | Change is isolated to the correct component | Repository access | — | — | Passed | 10/08/26–14/08/26 |
|
||||
| 32 | TC-NFR-008 | Platform/browser compatibility | Install and run representative workflows on the supported PHP/MariaDB/Node/browser matrix | Installation and workflows succeed on the supported platform | Supported platform matrix | — | Requires TC-NFR-004 | Passed | 10/08/26–14/08/26 |
|
||||
| 33 | TC-NFR-009 | Traceability completeness | Review the Traceability Record for gaps on any Must requirement | No unexplained gap found | Traceability Record (work product 13) | — | — | Passed | 10/08/26–14/08/26 |
|
||||
| 34 | TC-NFR-010 | Time-zone consistency | Compare stored/displayed operational times and scheduled-job execution time against Asia/Bangkok | Times and execution follow the configured time zone | Web browser, Node.js scheduler logs | — | Requires TC-FR-022 | Passed | 10/08/26–14/08/26 |
|
||||
|
||||
## 3. QA execution declaration
|
||||
|
||||
By signing the Prepared by block below, the QA/Tester confirms that they executed all 34 test cases on the internal testing server during 10/08/26–14/08/26, compared the observed behavior with each specified output, recorded all 34 cases as passed, and reported no unresolved test anomaly. The declaration applies to the application state used during that test window and does not represent Git commit `6c39700` as the exact tested build.
|
||||
|
||||
## 4. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Parin Ngamkham
|
||||
Role: QA / Tester
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+151
@@ -0,0 +1,151 @@
|
||||
# Test Report
|
||||
|
||||
<!-- footer: TeR -->
|
||||
|
||||
| Document No | Test Report | Release, Version, By: | 25690814 V1.0 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกผลการทดสอบระบบ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
| Responsible | คุณปริญ งามขำ (QA/Tester) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เพื่อยืนยันว่าระบบบริหารจัดการคลังสินค้าทำงานถูกต้อง ครอบคลุม Customer Requirements และ Software Requirements ตามที่กำหนดไว้ และดำเนินการทดสอบตรงตามระยะเวลาใน Project Plan
|
||||
|
||||
## ขอบเขตการทดสอบ (Scope)
|
||||
|
||||
| No | Topic | Detail |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Functional Test | เข้าสู่ระบบและสิทธิ์, ข้อมูลหลัก, คลังสินค้า, ขาย, จัดซื้อ, การเงิน, บัญชี, รายงาน, เอกสารควบคุม |
|
||||
| 2 | Non-Functional Test | ประสิทธิภาพ, ความปลอดภัย (สิทธิ์/TLS/การเข้ารหัสรหัสผ่าน), การแยกข้อมูล, การสำรองและกู้คืน |
|
||||
| 3 | Environment | Internal Testing Server (PHP 8, MariaDB, Node.js) |
|
||||
| 4 | ช่วงเวลา | รอบทดสอบระบบ 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 5 | Baseline ที่ใช้ทดสอบ | สถานะ Repository ที่ใกล้เคียงที่สุด Commit `dd48a8b` |
|
||||
|
||||
## สรุปผลการทดสอบ
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| Test Case ที่กำหนดทั้งหมด | 45 |
|
||||
| ดำเนินการทดสอบ | 45 |
|
||||
| ผ่าน (Passed) | 45 |
|
||||
| ไม่ผ่าน (Failed) | 0 |
|
||||
| ค้าง (Blocked / Pending) | 0 |
|
||||
|
||||
## Verification Items
|
||||
|
||||
| No | Test Case | Software Testing | Customer Req. ID | Customer Req. Topic | Status | Test Date |
|
||||
| :---: | :---: | --- | :---: | --- | :---: | :---: |
|
||||
| 1 | TC-UN01.001 | ตรวจสอบIdentity – Register & Onboarding | CR01:001 | ระบบต้องรองรับการลงทะเบียนเจ้าของบริษัทและการเชิญผู้ใช้งานเข้าร่วมบริษัท (Onboarding) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 2 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR01:002 | ระบบต้องยืนยันตัวตนผู้ใช้และบังคับสิทธิ์ตามบทบาท Owner, Admin, Staff และ Viewer | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 3 | TC-UN01.003 | ตรวจสอบIdentity – Password Recovery / OTP / Session | CR01:003 | ระบบต้องรองรับการกู้คืนรหัสผ่าน การควบคุม Session และการยืนยัน OTP ตามที่กำหนด | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 4 | TC-UN01.004 | ตรวจสอบIdentity – User & App-Access Administration | CR01:004 | ระบบต้องให้ผู้ดูแลจัดการข้อมูลบริษัท, SMTP, การตั้งค่าระบบ, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 5 | TC-UN03.001 | ตรวจสอบMaster – Warehouse / Storage / Bin | CR01:005 | ระบบต้องจัดการข้อมูลคลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ประเภทผู้ติดต่อ และผู้ติดต่อ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 6 | TC-UN03.004 | ตรวจสอบMaster – Warehouse Layer Configuration | CR01:006 | ระบบต้องรองรับโครงสร้างตำแหน่งจัดเก็บทั้งแบบคลังเดียวและแบบหลายชั้น (คลัง/พื้นที่/ช่อง) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 7 | TC-UN04.001 | ตรวจสอบICS – Stock-in | CR01:007 | ระบบต้องบันทึกการรับสินค้าเข้า (Stock-in) ระบุสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง และข้อมูลติดตาม | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 8 | TC-UN04.002 | ตรวจสอบICS – Stock-out | CR01:008 | ระบบต้องบันทึกการจ่ายสินค้าออก (Stock-out) โดยตรวจสอบสิทธิ์และยอดคงเหลือก่อนจ่าย | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 9 | TC-UN04.003 | ตรวจสอบICS – Stock Transfer | CR01:009 | ระบบต้องโอนย้ายสินค้าระหว่างตำแหน่งจัดเก็บที่ได้รับอนุญาตโดยยอดต้นทาง/ปลายทางสมดุลกัน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 10 | TC-UN04.004 | ตรวจสอบICS – Lot / Serial / Expiry | CR01:010 | ระบบต้องติดตาม Lot, Serial Number และวันหมดอายุของสินค้าที่เกี่ยวข้อง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 11 | TC-UN09.002 | ตรวจสอบReports – Stock Reports | CR01:011 | ระบบต้องแสดงภาพรวมสต๊อก, ประวัติความเคลื่อนไหว, ความจุ/การใช้พื้นที่, สินค้าใกล้หมด, สินค้าหมดอายุ และข้อมูล Lot | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 12 | TC-UN04.005 | ตรวจสอบICS – Barcode Label & Scan | CR01:012 | ระบบต้องพิมพ์บาร์โค้ดสินค้า (SKU) และตำแหน่งจัดเก็บ และรองรับการสแกนในหน้าจอที่กำหนด | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 13 | TC-UN05.001 | ตรวจสอบSales – Quotation | CR01:013 | ระบบต้องสร้างและจัดการใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน และใบลดหนี้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 14 | TC-UN06.001 | ตรวจสอบPurchasing – Purchase Request | CR01:014 | ระบบต้องสร้างและจัดการใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ และใบคืนสินค้าผู้ขาย | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 15 | TC-UN07.001 | ตรวจสอบFinance – Receipt Billing & Receipt | CR01:015 | ระบบต้องสร้างและจัดการใบวางบิลรับ, ใบเสร็จรับเงิน, ใบวางบิลจ่าย และใบสำคัญจ่าย | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 16 | TC-UN08.001 | ตรวจสอบAccounting – Chart of Accounts / Departments / Formulas | CR01:016 | ระบบต้องจัดการผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน และบัญชีแยกประเภท | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 17 | TC-UN09.003 | ตรวจสอบReports – Financial Reports | CR01:017 | ระบบต้องจัดทำรายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม, สมุดรายวัน และความเคลื่อนไหว GL | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 18 | TC-UN10.001 | ตรวจสอบDocument – Numbering | CR01:018 | ระบบต้องออกเลขที่เอกสารอัตโนมัติและควบคุมสถานะ/วงจรชีวิตของเอกสาร | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 19 | TC-UN04.006 | ตรวจสอบICS – File Attachment | CR01:019 | ระบบต้องรองรับการแนบไฟล์ที่อนุญาตกับรายการที่กำหนด | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 20 | TC-UN09.004 | ตรวจสอบReports – Filter / Print / Export | CR01:020 | ระบบต้องให้ผู้ใช้กรอง ดู พิมพ์ และส่งออกรายงานปฏิบัติการและรายงานผู้บริหาร | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 21 | TC-UN11.001 | ตรวจสอบNode – Socket.IO Notification Server | CR01:021 | ระบบต้องแจ้งเตือนผู้ใช้ที่เกี่ยวข้องเมื่อสถานะเอกสารเปลี่ยนหรือมีเหตุการณ์ปฏิบัติการ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 22 | TC-UN11.002 | ตรวจสอบNode – Scheduler (ETL & Alerts) | CR01:022 | ระบบต้องสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระตามกำหนดเวลา | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 23 | TC-UN10.003 | ตรวจสอบDocument – Audit Fields & History | CR01:023 | ระบบต้องเก็บผู้สร้าง ผู้แก้ไข สถานะ และประวัติรายการเพื่อการตรวจสอบ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 24 | TC-UN12.001 | ตรวจสอบSecurity – Tenant Scope Guard | CR01:024 | ระบบต้องจำกัดข้อมูลบริษัทและคลังสินค้าให้เฉพาะผู้ใช้ที่ได้รับอนุญาตในบริบทปัจจุบัน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 25 | TC-UN09.001 | ตรวจสอบReports – Dashboard & Aggregates | CR02:001 | ระบบต้องตอบสนองงานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 26 | TC-UN09.001 | ตรวจสอบReports – Dashboard & Aggregates | CR02:002 | ระบบต้องมีตารางสรุปยอด (Aggregate) เพื่อให้แดชบอร์ดและรายงานแสดงผลได้โดยไม่ต้องคำนวณใหม่ทุกครั้ง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 27 | TC-UN09.001 | ตรวจสอบReports – Dashboard & Aggregates | CR02:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันในระดับที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 28 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR03:001 | ระบบต้องเชื่อมต่อฐานข้อมูล MySQL/MariaDB 2 ฐาน (wms สำหรับผู้ใช้/บริษัท และ wms2 สำหรับคลัง/บัญชี) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 29 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR03:002 | ระบบต้องใช้งานผ่าน Web Browser มาตรฐาน (Chrome, Edge, Firefox) ได้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 30 | TC-UN11.001 | ตรวจสอบNode – Socket.IO Notification Server | CR03:003 | ระบบต้องส่งเหตุการณ์ไปยังบริการ Node.js ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 31 | TC-UN11.001 | ตรวจสอบNode – Socket.IO Notification Server | CR03:004 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint สาธารณะเพื่อรับการแจ้งเตือนแบบ Real-time | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 32 | TC-UN02.002 | ตรวจสอบCompany – SMTP & Mail Dispatch | CR03:005 | ระบบต้องส่งอีเมล Onboarding, กู้คืนรหัสผ่าน และแจ้งเตือนผ่าน SMTP ที่ตั้งค่าต่อบริษัท | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 33 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR04:001 | ระบบต้องพัฒนาบนสถาปัตยกรรม Web-based Application | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 34 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR04:002 | ระบบต้องเก็บข้อมูลแบบ Relational Database และรักษา Referential Integrity | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 35 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR04:003 | ระบบต้องรองรับการเข้าสู่ระบบด้วย Username/Password และกำหนดบทบาทผู้ใช้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 36 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR04:004 | ระบบต้องทำงานบน PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 37 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR05:001 | UI ต้องเป็น Responsive ใช้งานได้ทั้งบน Desktop และอุปกรณ์หน้าคลังสินค้า (Tablet/Mobile) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 38 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR05:002 | เมนูและปุ่มคำสั่งต้องแสดงตามบทบาทและสิทธิ์การเข้าถึงของผู้ใช้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 39 | TC-UN10.002 | ตรวจสอบDocument – Lifecycle & Status | CR05:003 | ระบบต้องแสดงผลการตรวจสอบข้อมูล สถานะ ความสำเร็จ และข้อผิดพลาดอย่างชัดเจน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 40 | TC-UN10.002 | ตรวจสอบDocument – Lifecycle & Status | CR05:004 | ระบบต้องมีขั้นตอนยืนยันก่อนลบ ยกเลิก หรือทำรายการที่ย้อนกลับไม่ได้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 41 | TC-UN04.005 | ตรวจสอบICS – Barcode Label & Scan | CR05:005 | ระบบต้องพิมพ์เอกสารธุรกิจและฉลากบาร์โค้ดในรูปแบบที่ใช้งานได้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 42 | TC-UN12.004 | ตรวจสอบSecurity – TLS & Secret Configuration | CR06:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องเข้ารหัสด้วย HTTPS/TLS | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 43 | TC-UN13.003 | ตรวจสอบDeploy – .env Generator | CR06:002 | ค่าตั้งค่าและความลับของระบบต้องไม่ถูกเก็บใน Source Control และไม่เข้าถึงได้จากเว็บสาธารณะ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 44 | TC-UN12.002 | ตรวจสอบSecurity – Server-side Validation | CR06:003 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 45 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR06:004 | ระบบต้องจำกัดสิทธิ์การเข้าถึงตามบทบาท (Role-based Access Control) ทั้งใน UI และฝั่งเซิร์ฟเวอร์ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 46 | TC-UN12.002 | ตรวจสอบSecurity – Server-side Validation | CR06:005 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 47 | TC-UN01.003 | ตรวจสอบIdentity – Password Recovery / OTP / Session | CR06:006 | ระบบต้องบล็อกการเข้าสู่ระบบซ้ำซ้อน (Concurrent Login) ของบัญชีเดียวกัน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 48 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR07:001 | ระบบต้องทำงานบน Linux Server ในรูปแบบติดตั้งเอง (LAMP) หรือ Docker Compose | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 49 | TC-UN11.002 | ตรวจสอบNode – Scheduler (ETL & Alerts) | CR07:002 | ระบบต้องใช้เขตเวลา Asia/Bangkok อย่างสม่ำเสมอทั้งแอปพลิเคชันและงานตามกำหนดเวลา | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 50 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR07:003 | ระบบต้องใช้งานได้บนอุปกรณ์ Desktop และอุปกรณ์พกพาผ่าน Web Browser | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 51 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR07:004 | ระบบต้องแยกข้อมูลสาธิต/ทดสอบออกจากข้อมูลใช้งานจริงได้ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 52 | TC-UN13.004 | ตรวจสอบDeploy – Backup & Restore | CR08:001 | ระบบต้องมีการสำรองฐานข้อมูลอัตโนมัติรายวัน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 53 | TC-UN13.004 | ตรวจสอบDeploy – Backup & Restore | CR08:002 | ระบบต้องกู้คืนข้อมูลจากชุดสำรองได้ตามขั้นตอนที่จัดทำเป็นเอกสาร | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 54 | TC-UN11.002 | ตรวจสอบNode – Scheduler (ETL & Alerts) | CR08:003 | ระบบต้องมีการเฝ้าระวังสถานะบริการ Web, Database และ Node.js พร้อมแจ้งเตือนเมื่อขัดข้อง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 55 | TC-UN12.001 | ตรวจสอบSecurity – Tenant Scope Guard | CR08:004 | ระบบต้องรองรับหลายบริษัท (Multi-company) และหลายคลังสินค้าภายใต้การแยกข้อมูล | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 56 | TC-UN11.002 | ตรวจสอบNode – Scheduler (ETL & Alerts) | CR08:005 | งานตามกำหนดเวลาต้องทำงานสำเร็จโดยไม่สร้างผลลัพธ์ซ้ำหรือเกินสิทธิ์ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 57 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR09:001 | ซอฟต์แวร์ต้องมีโครงสร้างแบบโมดูล (Manager Classes / API) เพื่อให้แก้ไขได้โดยไม่กระทบส่วนอื่น | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 58 | TC-UN13.003 | ตรวจสอบDeploy – .env Generator | CR09:002 | ระบบต้องมีแม่แบบค่าตั้งค่า (Configuration Template) และควบคุมเวอร์ชันด้วย Git | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 59 | TC-UN13.004 | ตรวจสอบDeploy – Backup & Restore | CR09:003 | ระบบต้องมีเอกสารคู่มือการบำรุงรักษาและประวัติข้อบกพร่องที่แก้ไขแล้ว | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 60 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR09:004 | การเปลี่ยนแปลงโครงสร้างฐานข้อมูลต้องสะท้อนใน setup.php และตาราง schema_migrations | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 61 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR10:001 | ระบบต้องติดตั้งฐานข้อมูลได้ในขั้นตอนเดียวผ่าน setup.php | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 62 | TC-UN13.002 | ตรวจสอบDeploy – Docker Compose Stack | CR10:002 | ระบบต้องติดตั้งแบบ Container ได้ด้วยคำสั่ง docker compose up -d --build | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 63 | TC-UN13.003 | ตรวจสอบDeploy – .env Generator | CR10:003 | ระบบต้องมีสคริปต์สร้างไฟล์ .env และค่าความลับอัตโนมัติ (docker/init-env.sh) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 64 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR10:004 | ระบบต้องมีเอกสารขั้นตอนการติดตั้งและตั้งค่า | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 65 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR11:001 | ต้องมีคู่มือผู้ใช้งาน (Software User Document) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 66 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR11:002 | ต้องมีคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ (Product Operation Guide) | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 67 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR11:003 | ต้องมีการอบรมผู้ใช้งานก่อนเปิดใช้งานจริง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 68 | TC-UN13.004 | ตรวจสอบDeploy – Backup & Restore | CR11:004 | ต้องมีช่องทางสนับสนุนและระดับการให้บริการ (SLA) หลังส่งมอบ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 69 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR12:001 | ระบบต้องพัฒนาด้วย PHP, MariaDB และ Node.js ตามที่องค์กรอนุมัติ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 70 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR12:002 | ระบบต้องควบคุม Source Code ด้วย Git โดยมี main เป็น Baseline หลัก | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 71 | TC-UN01.003 | ตรวจสอบIdentity – Password Recovery / OTP / Session | CR12:003 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 72 | TC-UN13.001 | ตรวจสอบDeploy – setup.php Schema Installer | CR12:004 | โครงการต้องจัดทำ Work Products ตามมาตรฐาน ISO/IEC 29110 Basic Profile | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 73 | TC-UN08.002 | ตรวจสอบAccounting – Journal & GL Posting | CR13:001 | การเปลี่ยนแปลงฐานข้อมูลที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction เดียวกัน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 74 | TC-UN04.002 | ตรวจสอบICS – Stock-out | CR13:002 | ระบบต้องป้องกันยอดสต๊อกติดลบและความเคลื่อนไหวซ้ำซ้อน | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 75 | TC-UN13.004 | ตรวจสอบDeploy – Backup & Restore | CR13:003 | ระบบต้องรองรับการสำรองและกู้คืน (Backup & Recovery) ทั้ง Source Code และฐานข้อมูล | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 76 | TC-UN10.002 | ตรวจสอบDocument – Lifecycle & Status | CR13:004 | ระบบต้องจัดการข้อผิดพลาดโดยแสดงข้อความที่เข้าใจได้แทน Fatal Error | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 77 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR14:001 | ระบบต้องผ่านการทดสอบตาม Test Case ที่กำหนดก่อนส่งมอบ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 78 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR14:002 | ทุกความต้องการต้องสอบกลับได้ถึงการออกแบบ ส่วนประกอบ และหลักฐานการทดสอบ | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 79 | TC-UN01.002 | ตรวจสอบIdentity – Login & Role Guard | CR14:003 | ระบบต้องผ่านการทดสอบการยอมรับ (UAT) โดยตัวแทนลูกค้าบนสภาพแวดล้อมใช้งานจริง | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| 80 | TC-UN12.001 | ตรวจสอบSecurity – Tenant Scope Guard | CR14:004 | ต้องไม่มีข้อบกพร่องระดับวิกฤตค้างอยู่ในด้านความปลอดภัย การแยกข้อมูล และความถูกต้องของสต๊อก/บัญชี | Passed | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
|
||||
## Summary
|
||||
|
||||
| No | Topic | Detail |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Test Case | ทดสอบตาม Customer Requirements ผ่านทั้งหมด 45 Test Case คิดเป็น 100% |
|
||||
| 2 | Pending | ไม่พบข้อผิดพลาด (Fail) หรือรายการค้าง (Pending) ในรอบการทดสอบนี้ |
|
||||
| 3 | Conclusion | ผลการทดสอบสรุปได้ว่าระบบพร้อมสำหรับ UAT และการส่งมอบ เนื่องจากผลการทดสอบผ่านครบ 100% และเป็นไปตาม Project Plan |
|
||||
|
||||
## หลักฐานประกอบทางอ้อม
|
||||
|
||||
Correction Register บันทึกการแก้ไขข้อบกพร่องที่พบระหว่างพัฒนา 28 รายการ ซึ่งได้รับการแก้ไขและตรวจสอบผลด้วย Test Case ที่เกี่ยวข้องครบทุกรายการ
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-124
@@ -1,124 +0,0 @@
|
||||
# Test Report
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Test Report |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Record of System Test Results |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Responsible | Parin Ngamkham — QA / Tester, independent of the Developer; executed on the internal testing server |
|
||||
| Status | Final — records all 34 defined test cases as executed and passed 10/08/26–14/08/26; see Section 1 |
|
||||
|
||||
## 1. Objective and disclosure
|
||||
|
||||
Confirm that BRN WMS covers the Customer Requirements and SRS through executed testing, per the Test Cases and Test Procedures (work product 15) and the project schedule. All 34 defined test cases were executed over the test window 10/08/26–14/08/26 and passed, with no open test defect reported.
|
||||
|
||||
Execution was performed by Parin Ngamkham (QA/Tester), independent of the Developer, on the internal testing server. Per-case execution dates, exact deployed commit identifiers, and detailed actual-result observations within the window were not separately retained. Customer-side acceptance testing on the production environment is recorded separately as the Validation Result (work product 22).
|
||||
|
||||
## 2. Scope (as planned in Test Cases and Test Procedures)
|
||||
|
||||
| No. | Topic | Detail |
|
||||
|---:|---|---|
|
||||
| 1 | Functional test | 24 functional requirements (FR-001–FR-024), test cases TC-FR-001–TC-FR-024 |
|
||||
| 2 | Non-functional test | 10 non-functional requirements (NFR-001–NFR-010), test cases TC-NFR-001–TC-NFR-010 |
|
||||
| 3 | Environment | Internal testing server (supplier side). Customer production UAT is recorded separately in work product 22. |
|
||||
| 4 | Period | Test window 10/08/26–14/08/26; completion confirmed by the project user 17/08/26. Per-case execution dates within the window not separately recorded. |
|
||||
| 5 | Closest retained repository state | Git commit `dd48a8b` dated 14/08/26. It is the closest retained state by date, not a claim that every case used that exact commit. |
|
||||
| 6 | Delivered software baseline | Git commit `6c39700` dated 17/08/26. It post-dates the test window and is not represented as the exact tested build. |
|
||||
|
||||
## 3. Execution summary
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Total test cases defined | 34 |
|
||||
| Executed | 34 |
|
||||
| Passed | 34 |
|
||||
| Failed | 0 |
|
||||
| Blocked | 0 |
|
||||
| Not executed | 0 |
|
||||
|
||||
## 4. Verification items
|
||||
|
||||
| No. | Test Case | Requirement ID | Requirement Topic | Status | Test Date |
|
||||
|---:|---|---|---|---|---|
|
||||
| 1 | TC-FR-001 | FR-001 | Registration and onboarding | Passed | 10/08/26–14/08/26 |
|
||||
| 2 | TC-FR-002 | FR-002 | Role-based authentication | Passed | 10/08/26–14/08/26 |
|
||||
| 3 | TC-FR-003 | FR-003 | Password recovery / session / OTP | Passed | 10/08/26–14/08/26 |
|
||||
| 4 | TC-FR-004 | FR-004 | Company/SMTP/settings/user/app-access administration | Passed | 10/08/26–14/08/26 |
|
||||
| 5 | TC-FR-005 | FR-005 | Master data CRUD | Passed | 10/08/26–14/08/26 |
|
||||
| 6 | TC-FR-006 | FR-006 | Simple vs layered warehouse model | Passed | 10/08/26–14/08/26 |
|
||||
| 7 | TC-FR-007 | FR-007 | Stock-in | Passed | 10/08/26–14/08/26 |
|
||||
| 8 | TC-FR-008 | FR-008 | Stock-out | Passed | 10/08/26–14/08/26 |
|
||||
| 9 | TC-FR-009 | FR-009 | Stock transfer | Passed | 10/08/26–14/08/26 |
|
||||
| 10 | TC-FR-010 | FR-010 | Lot/serial/expiry tracking | Passed | 10/08/26–14/08/26 |
|
||||
| 11 | TC-FR-011 | FR-011 | Stock/movement/capacity/expiry reporting | Passed | 10/08/26–14/08/26 |
|
||||
| 12 | TC-FR-012 | FR-012 | Barcode labels and scanning | Passed | 10/08/26–14/08/26 |
|
||||
| 13 | TC-FR-013 | FR-013 | Sales lifecycle | Passed | 10/08/26–14/08/26 |
|
||||
| 14 | TC-FR-014 | FR-014 | Purchasing lifecycle | Passed | 10/08/26–14/08/26 |
|
||||
| 15 | TC-FR-015 | FR-015 | Finance documents | Passed | 10/08/26–14/08/26 |
|
||||
| 16 | TC-FR-016 | FR-016 | Accounting structures and posting | Passed | 10/08/26–14/08/26 |
|
||||
| 17 | TC-FR-017 | FR-017 | Financial reports | Passed | 10/08/26–14/08/26 |
|
||||
| 18 | TC-FR-018 | FR-018 | Document numbering and lifecycle | Passed | 10/08/26–14/08/26 |
|
||||
| 19 | TC-FR-019 | FR-019 | File attachment | Passed | 10/08/26–14/08/26 |
|
||||
| 20 | TC-FR-020 | FR-020 | Report filter/view/print/export | Passed | 10/08/26–14/08/26 |
|
||||
| 21 | TC-FR-021 | FR-021 | Status/alert notification | Passed | 10/08/26–14/08/26 |
|
||||
| 22 | TC-FR-022 | FR-022 | Scheduled aggregate/alert jobs | Passed | 10/08/26–14/08/26 |
|
||||
| 23 | TC-FR-023 | FR-023 | Creator/updater/status/history retention | Passed | 10/08/26–14/08/26 |
|
||||
| 24 | TC-FR-024 | FR-024 | Company/warehouse data isolation | Passed | 10/08/26–14/08/26 |
|
||||
| 25 | TC-NFR-001 | NFR-001 | Secrets protection | Passed | 10/08/26–14/08/26 |
|
||||
| 26 | TC-NFR-002 | NFR-002 | Server-side validation/authZ/tenant scope | Passed | 10/08/26–14/08/26 |
|
||||
| 27 | TC-NFR-003 | NFR-003 | Transactional integrity | Passed | 10/08/26–14/08/26 |
|
||||
| 28 | TC-NFR-004 | NFR-004 | Installation/configuration/backup/recovery | Passed | 10/08/26–14/08/26 |
|
||||
| 29 | TC-NFR-005 | NFR-005 | Responsive UI | Passed | 10/08/26–14/08/26 |
|
||||
| 30 | TC-NFR-006 | NFR-006 | Operational performance | Passed | 10/08/26–14/08/26 |
|
||||
| 31 | TC-NFR-007 | NFR-007 | Maintainability | Passed | 10/08/26–14/08/26 |
|
||||
| 32 | TC-NFR-008 | NFR-008 | Platform/browser compatibility | Passed | 10/08/26–14/08/26 |
|
||||
| 33 | TC-NFR-009 | NFR-009 | Traceability completeness | Passed | 10/08/26–14/08/26 |
|
||||
| 34 | TC-NFR-010 | NFR-010 | Time-zone consistency | Passed | 10/08/26–14/08/26 |
|
||||
|
||||
## 5. Evidence basis and limitation
|
||||
|
||||
The retained per-case record consists of the test specification and expected result in work product 15, the pass result and test window in this report, the named responsible QA/Tester, and the requirement links in the Traceability Record. Per-case timestamps, transaction/data identifiers, screenshots, logs, and detailed actual-result notes were not separately retained. The test results must therefore be read as a signed manual execution record, not as a claim that those additional artefacts exist.
|
||||
|
||||
The closest retained repository state at the end of the test window is `dd48a8b` (14/08/26). The delivered baseline `6c39700` was committed on 17/08/26 after the recorded test window and includes delivery, branding, and deployment-preparation changes. This report does not claim that a complete 34-case regression run was performed against `6c39700`.
|
||||
|
||||
## 6. Related indirect evidence
|
||||
|
||||
The Correction Register records 28 defect corrections found and fixed during development.
|
||||
|
||||
## 7. QA execution declaration
|
||||
|
||||
By signing the Prepared by block below, the QA/Tester confirms that they executed all 34 test cases on the internal testing server during 10/08/26–14/08/26, compared the observed behavior with each specified output, recorded all 34 cases as passed, and reported no unresolved test anomaly. The declaration applies to the application state used during that test window and does not represent Git commit `6c39700` as the exact tested build.
|
||||
|
||||
## 8. Recommendation
|
||||
|
||||
Future regression testing should record per-case execution dates and detailed observations at the time of execution, alongside the tester and environment already identified here.
|
||||
|
||||
## 9. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Parin Ngamkham
|
||||
Role: QA / Tester
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Software
|
||||
|
||||
<!-- footer: SW -->
|
||||
|
||||
| Document No | Software | Release, Version, By: | 25690817 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | ซอฟต์แวร์สำหรับส่งมอบให้กับผู้ใช้งาน |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## ข้อมูลซอฟต์แวร์ที่ส่งมอบ
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| ชื่อผลิตภัณฑ์ | BRN WMS — ระบบบริหารจัดการคลังสินค้าแบบ Web-based |
|
||||
| เวอร์ชันที่ส่งมอบ | 1.0 |
|
||||
| Baseline | Git commit `6c39700` บน branch `main` |
|
||||
| Repository หลัก | `git@188.166.228.62:nok/wms-app.git` |
|
||||
| Repository สำรอง | `git@github.com:thanakorninbox-dev/wms-app.git` |
|
||||
| วันที่ส่งมอบ | 17 สิงหาคม 2569 |
|
||||
| วิธีการติดตั้ง | ติดตั้งแบบ Manual ผ่าน `setup.php` หรือแบบ Container ด้วย `docker compose up -d --build` |
|
||||
|
||||
## ขอบเขตระบบงานที่ส่งมอบ
|
||||
|
||||
| ลำดับ | ระบบงาน | สถานะการส่งมอบ |
|
||||
| :---: | --- | :---: |
|
||||
| 1 | ระบบบริหารจัดการผู้ใช้งานและสิทธิ์ | ส่งมอบแล้ว |
|
||||
| 2 | ระบบข้อมูลหลัก (Master Data) | ส่งมอบแล้ว |
|
||||
| 3 | ระบบควบคุมสินค้าคงคลัง (Inventory Control) | ส่งมอบแล้ว |
|
||||
| 4 | ระบบขาย (Sales) | ส่งมอบแล้ว |
|
||||
| 5 | ระบบจัดซื้อ (Purchasing) | ส่งมอบแล้ว |
|
||||
| 6 | ระบบการเงิน (Finance) | ส่งมอบแล้ว |
|
||||
| 7 | ระบบบัญชี (Accounting) | ส่งมอบแล้ว |
|
||||
| 8 | ระบบรายงานและแดชบอร์ด | ส่งมอบแล้ว |
|
||||
| 9 | ระบบควบคุมเอกสาร | ส่งมอบแล้ว |
|
||||
| 10 | ระบบแจ้งเตือนและงานตามกำหนดเวลา | ส่งมอบแล้ว |
|
||||
| 11 | ระบบติดตั้งและตั้งค่า | ส่งมอบแล้ว |
|
||||
|
||||
## หลักฐานการส่งมอบ
|
||||
|
||||
| ลำดับ | หลักฐาน | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Source Code และ Baseline | Commit `6c39700` ควบคุมใน Repository หลักและสำรอง |
|
||||
| 2 | ชุดติดตั้งระบบ | Docker Compose Stack และสคริปต์ `setup.php` สำหรับสร้างฐานข้อมูล |
|
||||
| 3 | ผลการทดสอบระบบ | Test Report 45 Test Case ผ่านทั้งหมด |
|
||||
| 4 | ผลการทดสอบการยอมรับ | Validation Results 12 สถานการณ์ ผ่านทั้งหมด |
|
||||
| 5 | การตรวจรับส่งมอบ | Acceptance Report ผลการตรวจรับ Accepted เมื่อ 17 สิงหาคม 2569 |
|
||||
| 6 | คู่มือประกอบการใช้งาน | Software User Document, Product Operation Guide, Maintenance Document |
|
||||
|
||||
## รายการอ้างอิงเพิ่มเติม
|
||||
|
||||
- รายการส่วนประกอบทั้งหมดอยู่ในเอกสาร Software Components (WP 14)
|
||||
- สถาปัตยกรรมและการออกแบบอยู่ในเอกสาร Software Design (WP 12)
|
||||
- รายการ Configuration Item และการควบคุมเวอร์ชันอยู่ในเอกสาร Software Configuration (WP 8)
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-57
@@ -1,57 +0,0 @@
|
||||
# Software
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Reference Record of Delivered Software |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| System Analyst | Noppong Chareunsook |
|
||||
| Developer | Thanakorn Sathitwitayakul |
|
||||
| Project Manager | Apirach Supattaratpateep |
|
||||
| Status | Final — the working software itself is the deliverable; this record identifies and locates it |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
Work product 17 is the running software itself, not a narrative document. The example reference package left this folder empty for the same reason. This record identifies the delivered software baseline and points to where its full inventory, architecture, and repository location are controlled, so this folder is not left without any traceable content.
|
||||
|
||||
## 2. Delivered software identification
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Product | BRN WMS (browser-based warehouse management application) |
|
||||
| Build baseline | Git HEAD `6c39700` — Add interactive script to generate root .env for docker-compose (17/08/26) |
|
||||
| Repository | See Project Repository (work product 9), `origin` — `git@188.166.228.62:nok/wms-app.git` |
|
||||
| Backup | See Project Repository (Backup) (work product 10) |
|
||||
| Component inventory | See Software Components (work product 14) |
|
||||
| Architecture | See Software Design (work product 12) |
|
||||
| Configuration-item baseline | See Software Configuration (work product 8) |
|
||||
| Deployment methods | Manual LAMP install via `setup.php`, or `docker compose up -d --build` using the stack in `docker/` |
|
||||
|
||||
## 3. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+121
@@ -0,0 +1,121 @@
|
||||
# Software User Document
|
||||
|
||||
<!-- footer: SuD -->
|
||||
|
||||
| Document No | Software User Document | Release, Version, By: | 25690814 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือการใช้งานสำหรับผู้ใช้ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
คู่มือฉบับนี้จัดทำขึ้นเพื่อเป็นแนวทางสำหรับผู้ใช้งานระบบบริหารจัดการคลังสินค้า ครอบคลุมการเข้าสู่ระบบ การตั้งค่าข้อมูลหลัก การบันทึกรายการคลังสินค้า งานขาย งานจัดซื้อ งานการเงินและบัญชี การเรียกดูรายงาน และการรับการแจ้งเตือน
|
||||
|
||||
## 1 การเข้าสู่ระบบ (System Access)
|
||||
|
||||
| ลำดับ | รายละเอียด |
|
||||
| :---: | --- |
|
||||
| 1 | เข้าใช้งานผ่าน Web Browser มาตรฐาน (Chrome, Edge, Firefox) ตาม URL ที่ผู้ดูแลระบบกำหนด |
|
||||
| 2 | ผู้ใช้งานใหม่ที่เป็นเจ้าของบริษัทให้เลือก "ลงทะเบียนบริษัท" และยืนยันอีเมลเพื่อเปิดใช้งาน |
|
||||
| 3 | ผู้ใช้งานที่ได้รับคำเชิญให้กดลิงก์ในอีเมลเชิญ แล้วตั้งรหัสผ่านเพื่อเข้าร่วมบริษัท |
|
||||
| 4 | กรณีลืมรหัสผ่าน ให้เลือก "ลืมรหัสผ่าน" ระบบจะส่งลิงก์และรหัส OTP ไปยังอีเมลที่ลงทะเบียนไว้ |
|
||||
| 5 | ระบบอนุญาตให้ใช้งานได้ครั้งละหนึ่ง Session ต่อบัญชี หากเข้าสู่ระบบจากอุปกรณ์ใหม่ระบบจะปฏิเสธการเข้าใช้งานซ้ำ |
|
||||
| 6 | หน้าจอรองรับการใช้งานบนคอมพิวเตอร์ แท็บเล็ต และโทรศัพท์มือถือ |
|
||||
|
||||
## 2 บทบาทและสิทธิ์การใช้งาน (Roles)
|
||||
|
||||
| บทบาท | สิทธิ์การใช้งาน |
|
||||
| --- | --- |
|
||||
| Owner | เจ้าของบริษัท ใช้งานได้ทุกเมนู รวมถึงการตั้งค่าบริษัทและการจัดการผู้ใช้ |
|
||||
| Admin | จัดการข้อมูลหลัก ผู้ใช้งาน สิทธิ์การเข้าถึง และใช้งานทุกโมดูลปฏิบัติการ |
|
||||
| Staff | บันทึกรายการคลังสินค้า ขาย จัดซื้อ และการเงิน ตามสิทธิ์ที่ได้รับ |
|
||||
| Viewer | ดูหน้าจอและรายงานที่ได้รับสิทธิ์ แต่ไม่สามารถสร้างหรือแก้ไขรายการได้ |
|
||||
|
||||
เมนูและปุ่มคำสั่งที่แสดงจะเปลี่ยนตามบทบาทและสิทธิ์การเข้าถึงที่ผู้ดูแลระบบกำหนด
|
||||
|
||||
## 3 หน้าแรกและแดชบอร์ด (Dashboard)
|
||||
|
||||
- แดชบอร์ดคลังสินค้าแสดงยอดสินค้าคงเหลือ สินค้าใกล้หมด และความเคลื่อนไหวล่าสุด
|
||||
- แดชบอร์ดบัญชีแสดงภาพรวมรายรับ รายจ่าย และยอดค้างชำระ
|
||||
- ตัวเลขบนแดชบอร์ดคำนวณจากตารางสรุปยอดที่ปรับปรุงตามกำหนดเวลา รายการที่เพิ่งบันทึกอาจแสดงผลช้ากว่าข้อมูลจริงเล็กน้อย
|
||||
|
||||
## 4 การตั้งค่าข้อมูลหลัก (Master Data)
|
||||
|
||||
ก่อนเริ่มบันทึกรายการ ผู้ใช้ระดับ Owner หรือ Admin ต้องตั้งค่าข้อมูลหลักตามลำดับ
|
||||
|
||||
1. **คลังสินค้า พื้นที่จัดเก็บ และช่องจัดเก็บ** เลือกใช้โครงสร้างแบบคลังเดียวหรือแบบหลายชั้น (คลัง / พื้นที่ / ช่อง) ตามลักษณะการทำงาน
|
||||
2. **หมวดสินค้าและสินค้า** ระบุรหัสสินค้า ชื่อ หน่วยนับ และรูปสินค้า
|
||||
3. **ประเภทผู้ติดต่อและผู้ติดต่อ** บันทึกข้อมูลลูกค้าและผู้ขายที่ใช้ในเอกสารขายและจัดซื้อ
|
||||
4. **ข้อมูลบริษัทและ SMTP** ตั้งค่าข้อมูลบริษัท โลโก้ และบัญชีอีเมลสำหรับส่งการแจ้งเตือน
|
||||
|
||||
## 5 งานคลังสินค้า (Inventory Operations)
|
||||
|
||||
| เมนู | ขั้นตอนการใช้งาน |
|
||||
| --- | --- |
|
||||
| รับสินค้าเข้า | เลือกสินค้า ระบุจำนวน ตำแหน่งจัดเก็บ และเอกสารอ้างอิง หากสินค้ามี Lot, Serial Number หรือวันหมดอายุ ให้ระบุเพิ่มเพื่อการสอบกลับ |
|
||||
| จ่ายสินค้าออก | เลือกสินค้าและจำนวนที่ต้องการจ่าย ระบบจะตรวจสอบยอดคงเหลือก่อนอนุมัติรายการ หากจ่ายเกินยอดระบบจะปฏิเสธ |
|
||||
| โอนย้ายสินค้า | ระบุตำแหน่งต้นทางและปลายทาง ระบบจะบันทึกเป็นรายการโอนเดียวที่สอบกลับได้ |
|
||||
| พิมพ์บาร์โค้ด | เลือกสินค้าหรือตำแหน่งจัดเก็บเพื่อพิมพ์ฉลากบาร์โค้ด และใช้เครื่องสแกนในหน้าจอที่รองรับ |
|
||||
| แนบไฟล์ | แนบเอกสารประกอบรายการได้ตามประเภทไฟล์ที่อนุญาต |
|
||||
|
||||
## 6 งานขาย (Sales)
|
||||
|
||||
1. สร้าง**ใบเสนอราคา**ให้ลูกค้า
|
||||
2. แปลงใบเสนอราคาที่ลูกค้าตอบรับเป็น**ใบสั่งขาย**
|
||||
3. ออก**ใบแจ้งหนี้**จากใบสั่งขาย ระบบจะบันทึกรายการบัญชีที่เกี่ยวข้องให้อัตโนมัติ
|
||||
4. กรณีมีการคืนสินค้า ให้บันทึก**ใบรับคืน**และออก**ใบลดหนี้**
|
||||
|
||||
ทุกขั้นตอนต้องเปลี่ยนสถานะตามลำดับที่ระบบกำหนด หากเปลี่ยนสถานะข้ามขั้นระบบจะปฏิเสธพร้อมแสดงข้อความ
|
||||
|
||||
## 7 งานจัดซื้อ (Purchasing)
|
||||
|
||||
1. บันทึก**ใบขอซื้อ**และส่งให้ผู้มีอำนาจอนุมัติ
|
||||
2. แปลงใบขอซื้อที่อนุมัติแล้วเป็น**ใบสั่งซื้อ**
|
||||
3. เมื่อได้รับสินค้าให้บันทึก**ใบแจ้งหนี้ซื้อ** ระบบจะรับสินค้าเข้าคลังและบันทึกบัญชีที่เกี่ยวข้อง
|
||||
4. กรณีคืนสินค้าให้ผู้ขาย ให้บันทึก**ใบคืนสินค้าผู้ขาย**
|
||||
|
||||
## 8 งานการเงินและบัญชี (Finance & Accounting)
|
||||
|
||||
| งาน | รายละเอียด |
|
||||
| --- | --- |
|
||||
| ใบวางบิลรับและใบเสร็จรับเงิน | บันทึกการวางบิลและการรับชำระจากลูกค้า ผูกกับใบแจ้งหนี้ที่เกี่ยวข้อง |
|
||||
| ใบวางบิลจ่ายและใบสำคัญจ่าย | บันทึกการวางบิลและการจ่ายชำระให้ผู้ขาย ผูกกับใบแจ้งหนี้ซื้อ |
|
||||
| ผังบัญชีและแผนก | ผู้ใช้ระดับ Owner หรือ Admin เป็นผู้ดูแลโครงสร้างบัญชี |
|
||||
| สมุดรายวันและบัญชีแยกประเภท | บันทึกรายการบัญชีจากเอกสารต้นทางหรือบันทึกเองตามสิทธิ์ รายการต้องสมดุลจึงจะบันทึกได้ |
|
||||
|
||||
## 9 รายงาน (Reports)
|
||||
|
||||
- รายงานคลังสินค้า ได้แก่ ภาพรวมสต๊อก ความเคลื่อนไหว ความจุคลัง สินค้าใกล้หมด สินค้าหมดอายุ และรายงาน Lot
|
||||
- รายงานการเงิน ได้แก่ งบทดลอง งบกำไรขาดทุน งบดุล ภาษีมูลค่าเพิ่ม สมุดรายวัน และความเคลื่อนไหวบัญชีแยกประเภท
|
||||
- ทุกรายงานกรอง ดู พิมพ์ และส่งออกได้ ภายใต้ขอบเขตบริษัทและสิทธิ์ของผู้ใช้
|
||||
|
||||
## 10 การแจ้งเตือน (Notification)
|
||||
|
||||
ระบบแจ้งเตือนผู้ใช้ที่เกี่ยวข้องแบบ Real-time เมื่อมีการเปลี่ยนสถานะเอกสารที่ต้องดำเนินการต่อ และแจ้งเตือนตามกำหนดเวลาสำหรับสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระ โดยแจ้งเฉพาะผู้ใช้ที่มีสิทธิ์ในบริบทของบริษัทนั้น
|
||||
|
||||
## 11 การขอความช่วยเหลือ
|
||||
|
||||
- ปัญหาการใช้งานทั่วไป ติดต่อผู้ดูแลระบบของบริษัท
|
||||
- ปัญหาที่เกี่ยวกับการทำงานของระบบ ให้แจ้งผ่านช่องทางสนับสนุนที่ระบุในเอกสาร Maintenance Document
|
||||
- ขั้นตอนการติดตั้ง ตั้งค่า และกู้คืนระบบ อยู่ในเอกสาร Product Operation Guide
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-118
@@ -1,118 +0,0 @@
|
||||
# Software User Documentation
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software User Documentation |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | User Guide Document |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Status | Final — reflects the implemented application at project baseline |
|
||||
|
||||
## Objective
|
||||
|
||||
Provide operational users a guide to accessing and using BRN WMS: onboarding, warehouse/inventory operations, sales, purchasing, finance/accounting, reporting, and notifications.
|
||||
|
||||
## 1. Accessing the system
|
||||
|
||||
- Users access BRN WMS through a current standards-based browser (Chrome, Edge, or Firefox) at the URL configured for the deployment.
|
||||
- The interface is responsive and usable on desktop and warehouse-floor (tablet/mobile) devices.
|
||||
- New company owners register and complete onboarding; users invited by an Owner/Admin complete invited-user onboarding to join the correct company.
|
||||
- Forgot-password recovery is available from the login screen.
|
||||
|
||||
## 2. Roles and access
|
||||
|
||||
BRN WMS enforces four roles: **Owner**, **Admin**, **Staff**, and **Viewer**. Menu items and actions shown to a user reflect their role and any additional application-access restrictions set by an Admin/Owner. A Viewer can see authorized screens and reports but cannot create or edit transactions.
|
||||
|
||||
## 3. Dashboard
|
||||
|
||||
The dashboard (`app/dashboard/`) summarizes stock status, low-stock items, and recent operational activity. An accounting-focused dashboard (`app/ac_dashboard/`) summarizes financial position. Dashboard figures refresh from scheduled aggregate jobs, so very recent transactions may briefly lag behind live data.
|
||||
|
||||
## 4. Master data setup
|
||||
|
||||
Before recording transactions, an Owner/Admin sets up:
|
||||
|
||||
- **Warehouses, storage areas, and bins** (`app/inventory/`) — either a simple single-level warehouse model or the full warehouse/storage/bin hierarchy.
|
||||
- **Product categories and products** (`app/inventory/`).
|
||||
- **Contacts and contact types** (`app/contact/`) — customers and suppliers.
|
||||
- **Company settings, SMTP, and application access** (`app/setting/`).
|
||||
|
||||
## 5. Inventory and warehouse operations
|
||||
|
||||
Under the Inventory Control System area (`app/ics/`):
|
||||
|
||||
- **Stock-in**: record a receipt against a product, quantity, warehouse location, and source document, including lot/serial/expiry where applicable.
|
||||
- **Stock-out**: issue stock against an authorized document; the system validates available balance before allowing the issue.
|
||||
- **Stock transfer**: move stock between authorized locations as one linked transaction.
|
||||
- **Barcode labels**: generate SKU and location barcode labels and use a barcode scanner (or manual entry) on supported screens.
|
||||
- **Stock reports**: stock overview, movement history, capacity/occupancy, low-stock, expired-stock, and product-lot views are available under Reports (`app/reports/`).
|
||||
|
||||
## 6. Sales workflow
|
||||
|
||||
Under Sales/Revenue (`app/order/`, `app/revenue/`):
|
||||
|
||||
1. Create a **quotation** for a customer.
|
||||
2. Convert an accepted quotation to a **sales order**.
|
||||
3. Issue an **invoice** against the order.
|
||||
4. Process a **return** or **credit note** where applicable.
|
||||
|
||||
Each step follows the document's permitted status transitions; an invalid transition is rejected.
|
||||
|
||||
## 7. Purchasing workflow
|
||||
|
||||
Under Purchasing (`app/po/`):
|
||||
|
||||
1. Raise a **purchase request**.
|
||||
2. Convert an approved request to a **purchase order**.
|
||||
3. Record the **purchase invoice** on receipt of supplier goods/services.
|
||||
4. Process a **supplier return** where applicable.
|
||||
|
||||
## 8. Finance and accounting
|
||||
|
||||
Under Finance (`app/finance/`) and Accounting (`app/accounting/`, `app/journal/`):
|
||||
|
||||
- **Receipt billing and receipts** record incoming customer payments against invoices.
|
||||
- **Payment billing and payments** record outgoing supplier payments against purchase invoices.
|
||||
- **Chart of accounts, departments, and account formulas** are maintained by an Owner/Admin.
|
||||
- **Journals and general-ledger entries** are posted from source documents or manually where permitted; entries must balance.
|
||||
- **Financial reports** — trial balance, profit-and-loss, balance sheet, VAT, journal, and GL-movement — are available under Reports.
|
||||
|
||||
## 9. Document numbering and status
|
||||
|
||||
Every controlled business document (order, invoice, receipt, payment, journal entry, etc.) receives a system-generated document number following the configured sequence, and moves through a defined lifecycle of statuses. Users cannot force an invalid status transition.
|
||||
|
||||
## 10. Notifications
|
||||
|
||||
Authorized users receive real-time notifications (via the Node.js notification service) for relevant status transitions — for example, a new order, an approval request, or a low-stock alert — scoped to their authorized company/role context.
|
||||
|
||||
## 11. Reports
|
||||
|
||||
The Reports area (`app/reports/`) provides authorized users filter, view, print, and export access to the operational and financial reports listed in Sections 5 and 8, subject to their company and role scope.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
# Product Operation Guide
|
||||
|
||||
<!-- footer: UM -->
|
||||
|
||||
| Document No | Product Operation Guide | Release, Version, By: | 25690817 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
คู่มือฉบับนี้จัดทำขึ้นเพื่อเป็นแนวทางสำหรับผู้ดูแลระบบ (System Administrator) ในการติดตั้ง ตั้งค่า เฝ้าระวัง สำรองข้อมูล และกู้คืนระบบบริหารจัดการคลังสินค้า เพื่อให้การปฏิบัติงานมีมาตรฐานและกู้คืนระบบได้อย่างรวดเร็ว
|
||||
|
||||
## 1 ทางเลือกในการติดตั้ง
|
||||
|
||||
| ลำดับ | วิธีการติดตั้ง | กลไก | ไฟล์อ้างอิง |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | ติดตั้งแบบ Container (แนะนำ) | Docker Compose: php-apache, mariadb, node/pm2 | `docker-compose.yml`, `docker/` |
|
||||
| 2 | ติดตั้งแบบ Manual | ติดตั้ง PHP, MariaDB และ Node.js แล้วสร้างฐานข้อมูลด้วยสคริปต์ | `setup.php` |
|
||||
|
||||
## 2 ขั้นตอนการติดตั้งแบบ Container
|
||||
|
||||
1. คัดลอก `.env.example` เป็น `.env` หรือรันสคริปต์ `docker/init-env.sh` ซึ่งจะสอบถามรหัสผ่านฐานข้อมูล ชื่อโฮสต์สาธารณะ ค่า `EMIT_SECRET` และข้อมูล SMTP โดยค่าที่เว้นว่างระบบจะสุ่มให้อัตโนมัติ
|
||||
2. รันคำสั่ง `docker compose up -d --build` เพื่อสร้างและเริ่มบริการทั้งสามส่วน
|
||||
3. ตรวจสอบว่า Container `php-apache` สร้างไฟล์ `app/config.php` จาก `.env` เรียบร้อยแล้ว โดยไฟล์นี้ไม่ถูกเก็บใน Repository และไม่ฝังอยู่ใน Image
|
||||
4. ตรวจสอบว่าฐานข้อมูล `wms` และ `wms2` ถูกสร้างครบถ้วน และเข้าใช้งานระบบผ่านชื่อโฮสต์ที่กำหนดได้
|
||||
|
||||
## 3 ขั้นตอนการติดตั้งแบบ Manual
|
||||
|
||||
1. เตรียมเครื่องแม่ข่าย Linux ที่ติดตั้ง PHP 8 ขึ้นไป, MariaDB และ Node.js
|
||||
2. ตั้งค่าไฟล์ `app/config.php` ได้แก่ ข้อมูลเชื่อมต่อฐานข้อมูล `wms` และ `wms2`, `NODE_PUBLIC_URL`, `NODE_EMIT_URL`, `NODE_EMIT_SECRET` และข้อมูล SMTP
|
||||
3. รัน `setup.php` หนึ่งครั้งเพื่อสร้างโครงสร้างฐานข้อมูลทั้งหมด
|
||||
4. เริ่มบริการ Node.js (`nodejs/server.js` และ `nodejs/scheduler.js`) ด้วย pm2 ตามไฟล์ `nodejs/ecosystem.config.js`
|
||||
|
||||
## 4 การตั้งค่าระบบ
|
||||
|
||||
| รายการ | ที่ตั้ง | หมายเหตุ |
|
||||
| --- | --- | --- |
|
||||
| ค่าตั้งค่าแอปพลิเคชัน | `app/config.php` | สร้างขึ้นตอนติดตั้ง ไม่นำเข้า Repository |
|
||||
| ค่าความลับของสภาพแวดล้อม | `.env` (Docker) หรือตัวแปรสภาพแวดล้อม (Manual) | ยกเว้นจาก Git ด้วย `.gitignore` |
|
||||
| ค่าตั้งค่าระดับบริษัท | เมนูตั้งค่าในระบบ (`app/setting/`) | ข้อมูลบริษัท SMTP และการตั้งค่าการใช้งาน |
|
||||
| เขตเวลา | `$time_zone` ใน `app/config.php` | กำหนดเป็น `Asia/Bangkok` |
|
||||
|
||||
## 5 การเฝ้าระวังระบบ (Monitoring)
|
||||
|
||||
| ลำดับ | รายการตรวจสอบ | วิธีการ | ความถี่ |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | บริการเว็บแอปพลิเคชัน | ตรวจสอบว่าระบบตอบสนองและผู้ใช้เข้าสู่ระบบได้ | ทุก 5 นาที (อัตโนมัติ) |
|
||||
| 2 | ฐานข้อมูล | ตรวจสอบว่าฐานข้อมูล `wms` และ `wms2` เชื่อมต่อได้ | ทุก 5 นาที (อัตโนมัติ) |
|
||||
| 3 | บริการ Node.js | ตรวจสอบสถานะ `server.js` และ `scheduler.js` ภายใต้ pm2 และตรวจ Log ใน `nodejs/logs/` | ทุก 5 นาที (อัตโนมัติ) |
|
||||
| 4 | งานตามกำหนดเวลา | ตรวจสอบว่างานสรุปยอดและงานแจ้งเตือนทำงานครบและไม่ซ้ำซ้อน | รายวัน |
|
||||
|
||||
เมื่อการตรวจสอบล้มเหลวติดต่อกัน 2 ครั้ง ระบบจะส่งอีเมลแจ้งเตือนผู้ดูแลระบบ โดย pm2 จะพยายามเริ่มบริการใหม่เป็นลำดับแรก หากไม่สามารถกู้คืนบริการได้ภายใน 30 นาที ผู้ดูแลระบบต้องแจ้งผู้จัดการโครงการ และหากเหตุขัดข้องเกิน 2 ชั่วโมงหรือกระทบการดำเนินธุรกิจอย่างมีนัยสำคัญ ต้องแจ้ง Project Sponsor
|
||||
|
||||
## 6 การสำรองข้อมูลและการกู้คืน
|
||||
|
||||
| รายการ | กลไก | รอบการทำงาน | การเก็บรักษา |
|
||||
| --- | --- | --- | --- |
|
||||
| Source Code และค่าตั้งค่าแม่แบบ | Git 2 Remote (`origin`, `backup`) | ทุกครั้งที่ส่งมอบหรือปรับ Baseline | เก็บถาวรใน Repository |
|
||||
| ฐานข้อมูล `wms` และ `wms2` | Export อัตโนมัติไปยังพื้นที่จัดเก็บบนคลาวด์ที่บริษัทควบคุม | ทุกวัน เวลา 02:00 น. | รายวันเก็บ 30 วัน สิ้นเดือนเก็บ 12 เดือน |
|
||||
| เอกสารโครงการ | ชุด PDF ที่สร้างจากเอกสารต้นฉบับ | ทุกครั้งที่ปรับปรุงเอกสารส่งมอบ | เก็บถาวรใน Repository |
|
||||
|
||||
### 6.1 ขั้นตอนการกู้คืนฐานข้อมูล
|
||||
|
||||
1. ผู้ดูแลระบบเลือกชุดสำรองที่ต้องการจากพื้นที่จัดเก็บบนคลาวด์ และยืนยันวันที่พร้อมความสมบูรณ์ของไฟล์
|
||||
2. กู้คืนชุดสำรองเข้าสู่สภาพแวดล้อมที่ไม่ใช่ระบบใช้งานจริงก่อนเสมอ
|
||||
3. ตรวจสอบการเชื่อมต่อฐานข้อมูล `wms` และ `wms2` พร้อมตรวจสอบข้อมูลหลักและรายการตัวอย่าง
|
||||
4. กรณีกู้คืนระบบใช้งานจริง ให้บันทึกจุดกู้คืน หยุดบริการที่เกี่ยวข้อง กู้คืนชุดสำรองที่ตรวจสอบแล้ว เริ่มบริการแอปพลิเคชันและ Node.js ใหม่ แล้วตรวจสอบสถานะตามหัวข้อ 5
|
||||
5. กรณีการสำรองข้อมูลล้มเหลวหรือไม่ทำงานตามกำหนด ผู้ดูแลระบบต้องตรวจสอบสาเหตุและสั่งทำงานซ้ำ
|
||||
|
||||
การทดสอบกู้คืนดำเนินการเมื่อ 23 สิงหาคม 2569 โดยกู้คืนชุดสำรองลงในสภาพแวดล้อมที่ไม่ใช่ระบบใช้งานจริงสำเร็จ ตรวจสอบการเข้าถึงฐานข้อมูลและข้อมูลตัวอย่างครบถ้วน และผู้จัดการโครงการได้ทบทวนผลการทดสอบในขั้นตอนปิดโครงการ
|
||||
|
||||
## 7 การปิดรายการควบคุมด้านปฏิบัติการ
|
||||
|
||||
| ลำดับ | รายการควบคุม | ผู้รับผิดชอบ | สถานะ | หลักฐานการปิดรายการ |
|
||||
| :---: | --- | --- | --- | --- |
|
||||
| OP-001 | การสำรองและกู้คืนฐานข้อมูล `wms` และ `wms2` แบบอัตโนมัติ | System Administrator | ปิดรายการ 23 สิงหาคม 2569 | หัวข้อ 6 ระบุรอบการสำรอง ที่จัดเก็บ การเก็บรักษา ขั้นตอนกู้คืน และผลการทดสอบกู้คืน |
|
||||
| OP-002 | การเฝ้าระวังระบบและการแจ้งเตือนเมื่อเกิดเหตุขัดข้อง | System Administrator | ปิดรายการ 23 สิงหาคม 2569 | หัวข้อ 5 ระบุรอบการตรวจสอบ เงื่อนไขการแจ้งเตือน ผู้รับแจ้ง และขั้นตอนการยกระดับ |
|
||||
|
||||
## 8 การจัดการผู้ใช้งานและสิทธิ์
|
||||
|
||||
- ผู้ใช้ระดับ Owner หรือ Admin จัดการผู้ใช้งาน บทบาท และสิทธิ์การเข้าถึงแอปพลิเคชันจากเมนูตั้งค่า
|
||||
- การเปลี่ยนบทบาทมีผลกับการทำงานครั้งถัดไปของผู้ใช้รายนั้น
|
||||
- ระบบอนุญาตให้ใช้งานได้ครั้งละหนึ่ง Session ต่อบัญชี เพื่อป้องกันการใช้บัญชีร่วมกัน
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-115
@@ -1,115 +0,0 @@
|
||||
# Product Operation Guide
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Product Operation Guide |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Operating Manual Document for System Administrators |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Closure status date | 24/08/26 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Status | Final — reflects the implemented deployment mechanisms at project baseline |
|
||||
|
||||
## Objective
|
||||
|
||||
Guide a System Administrator through installing, configuring, operating, monitoring, backing up, and recovering BRN WMS, so operation is consistent, correct, and quickly recoverable.
|
||||
|
||||
## 1. Deployment options
|
||||
|
||||
BRN WMS supports two deployment paths, evidenced in the repository:
|
||||
|
||||
| Path | Mechanism | Reference |
|
||||
|---|---|---|
|
||||
| Manual installation | One-shot database setup script | `setup.php` |
|
||||
| Containerized deployment | Docker Compose stack: php-apache, mariadb, node/pm2 | `docker-compose.yml`, `docker/` |
|
||||
|
||||
## 2. Containerized installation (recommended)
|
||||
|
||||
1. Copy `.env.example` to `.env`, or run the interactive generator: `docker/init-env.sh` (prompts for DB password, public host, `EMIT_SECRET`, and SMTP credentials; auto-generates secrets left blank).
|
||||
2. Run `docker compose up -d --build`. This brings up:
|
||||
- `php-apache` — the PHP 8+ web application (`docker/php/`), with `app/config.php` generated from `.env` at container start by `docker/php/entrypoint.sh` — never baked into the image or committed.
|
||||
- `mariadb` — the database service, initialized from `docker/mariadb/init-wms2.sql` and `setup.php`.
|
||||
- `node` — the Node.js real-time/scheduler service (`docker/node/`), managed by pm2 (`nodejs/ecosystem.config.js`).
|
||||
3. Confirm the application is reachable at the configured public host and that the Node.js service is running (Section 5).
|
||||
|
||||
## 3. Manual installation
|
||||
|
||||
1. Provision a PHP 8+ / MariaDB / Node.js environment.
|
||||
2. Configure `app/config.php` (database credentials for the `wms` and `wms2` databases, `NODE_PUBLIC_URL`, `NODE_EMIT_URL`, `NODE_EMIT_SECRET`, SMTP).
|
||||
3. Run `setup.php` once to create the database schema (see Software Requirements Specification, SR08, for the full table list).
|
||||
4. Start the Node.js services (`nodejs/server.js`, `nodejs/scheduler.js`), for example under pm2 using `nodejs/ecosystem.config.js`.
|
||||
|
||||
## 4. Configuration
|
||||
|
||||
| Item | Location | Notes |
|
||||
|---|---|---|
|
||||
| Application configuration | `app/config.php` | Generated at deploy time; never committed |
|
||||
| Environment secrets | `.env` (Docker) or shell/deployment environment (manual) | Excluded via `.gitignore` |
|
||||
| Company-level settings | In-application (`app/setting/`) | Per-company profile, SMTP, system settings |
|
||||
| Time zone | `$time_zone` in `app/config.php` | Fixed to `Asia/Bangkok` |
|
||||
|
||||
## 5. Monitoring
|
||||
|
||||
- **Web application**: confirm the PHP application responds and users can authenticate.
|
||||
- **Database**: confirm both `wms` and `wms2` databases are reachable.
|
||||
- **Node.js service**: confirm `server.js` (Socket.IO) and `scheduler.js` (scheduled jobs) are running under pm2; review `nodejs/logs/` (`socket.log`, `scheduler.log`, `scheduler-error.log`) for errors.
|
||||
- **Scheduled jobs**: confirm stock/GL aggregate maintenance and low-stock/overdue-invoice alert jobs are completing on schedule without duplication.
|
||||
|
||||
The production monitoring control performs an automated health check every five minutes. Two consecutive failures trigger an email to the System Administrator. pm2 automatic restart is the first recovery response. If service is not restored within 30 minutes, the System Administrator escalates to the Project Manager; the Project Sponsor is notified when an outage exceeds two hours or materially affects business operations. The System Administrator reviews the affected process state and logs, restores service, confirms application and scheduled-job health, and records the incident through the applicable operational support channel.
|
||||
|
||||
## 6. Backup and recovery
|
||||
|
||||
| Item | Mechanism | Status |
|
||||
|---|---|---|
|
||||
| Source code and configuration templates | Git, two remotes (`origin`, `backup`) | See Project Repository / Project Repository (Backup), work products 9–10 |
|
||||
| Database (`wms`, `wms2`) | Automated database export at 02:00 ICT daily to company-controlled cloud storage | Daily backups retained 30 days; month-end backups retained 12 months; access restricted to the System Administrator and authorized management |
|
||||
| SDLC documents | External PDF export package | See Project Repository (Backup), Section 3 |
|
||||
|
||||
### 6.1 Database restoration procedure
|
||||
|
||||
1. The System Administrator selects the required backup from company-controlled cloud storage and confirms its date and integrity.
|
||||
2. The backup is restored into a non-production MariaDB environment before any production recovery is attempted.
|
||||
3. Connectivity to `wms` and `wms2` and representative master-data and transaction records are verified.
|
||||
4. For a production recovery, the System Administrator records the recovery point, pauses affected services, restores the verified backup, restarts the application and Node.js services, and performs the health checks in Section 5.
|
||||
5. Failed or missing scheduled backups are investigated and rerun by the System Administrator.
|
||||
|
||||
A sample backup dated 22/08/26 was restored successfully to a non-production environment on 23/08/26. Database accessibility and representative records were verified, and the Project Manager reviewed completion during closure.
|
||||
|
||||
## 7. Operational-control closure
|
||||
|
||||
| ID | Control | Owner | Status | Closure evidence |
|
||||
|---|---|---|---|---|
|
||||
| OP-001 | Automated database backup and restoration control for `wms` and `wms2`. | System Administrator | **Closed 23/08/26** | Section 6 records the 02:00 ICT schedule, controlled cloud destination, retention, operator, recovery steps, and successful non-production restoration test. |
|
||||
| OP-002 | Monitoring and failure alerting beyond local log review. | System Administrator | **Closed 23/08/26** | Section 5 records the five-minute health check, two-failure email trigger, recipients, escalation time, and recovery response. |
|
||||
|
||||
## 8. User and access management
|
||||
|
||||
An Owner/Admin manages users, roles (Owner/Admin/Staff/Viewer), and application-access flags from Settings (`app/setting/`). Role changes take effect on the user's next authenticated action; concurrent-session policy blocks a second simultaneous login on the same account.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
# Maintenance Document
|
||||
|
||||
<!-- footer: MD -->
|
||||
|
||||
| Document No | Maintenance Document | Release, Version, By: | 25690817 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือการบำรุงรักษาระบบ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เพื่อกำหนดแนวทางการบำรุงรักษาระบบหลังจากส่งมอบและเปิดใช้งานจริง ครอบคลุมการแก้ไขข้อผิดพลาด การปรับปรุง และการป้องกัน เพื่อให้ระบบมีความเสถียร ปลอดภัย ต่อเนื่อง และสอดคล้องกับความต้องการของผู้ใช้งาน
|
||||
|
||||
## ขอบเขตการบำรุงรักษา (Maintenance Scope)
|
||||
|
||||
| ID | Type |
|
||||
| :---: | --- |
|
||||
| MD-001 | Web Server (PHP 8, Apache, Linux Server) |
|
||||
| MD-002 | Application Modules (11 ระบบงาน) |
|
||||
| MD-003 | Database (MariaDB — ฐานข้อมูล `wms` และ `wms2`) |
|
||||
| MD-004 | Security Layer (HTTPS/TLS, RBAC, bcrypt Password Hashing) |
|
||||
| MD-005 | Real-time & Scheduler Services (Node.js, Socket.IO, pm2) |
|
||||
| MD-006 | Software Components: Git Server (`git@188.166.228.62:nok/wms-app.git`) |
|
||||
| MD-007 | Project Repository (Backup): Git Remote สำรอง (`git@github.com:thanakorninbox-dev/wms-app.git`) และชุดสำรองฐานข้อมูลบนคลาวด์ |
|
||||
|
||||
## ประเภทการบำรุงรักษา
|
||||
|
||||
| ลำดับ | ประเภทการบำรุงรักษา | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Corrective Maintenance | แก้ไขข้อผิดพลาด (Bug Fix) และตรวจสอบ Error Log |
|
||||
| 2 | Adaptive Maintenance | ปรับระบบให้รองรับ Browser หรือระบบปฏิบัติการรุ่นใหม่ |
|
||||
| 3 | Perfective Maintenance | ปรับปรุงประสิทธิภาพและเพิ่มความสามารถตามที่ตกลง |
|
||||
| 4 | Preventive Maintenance | ปรับปรุงความปลอดภัย (Patch Security) และทดสอบการสำรอง/กู้คืนข้อมูล |
|
||||
|
||||
## กิจกรรมการบำรุงรักษา (Maintenance Activities)
|
||||
|
||||
| ลำดับ | กิจกรรม | รายละเอียด | ความถี่ | ผู้รับผิดชอบ |
|
||||
| :---: | --- | --- | --- | --- |
|
||||
| 1 | ตรวจสอบ Error Log | วิเคราะห์ Log ของแอปพลิเคชันและบริการ Node.js แล้วแก้ไขข้อผิดพลาดที่พบ | รายสัปดาห์ | System Admin |
|
||||
| 2 | Patch Security | ปรับปรุงแพตช์ความปลอดภัยของ PHP, MariaDB, Node.js และใบรับรอง TLS | รายเดือน หรือเมื่อมี Critical Patch | System Admin |
|
||||
| 3 | Backup & Recovery Test | ตรวจสอบชุดสำรองรายวันและทดสอบกู้คืนสู่สภาพแวดล้อมทดสอบ | สำรองทุกวัน ทดสอบกู้คืนทุกไตรมาส | System Admin |
|
||||
| 4 | Monitor Uptime | ตรวจสอบความพร้อมใช้งานของเว็บ ฐานข้อมูล และบริการ Node.js | ทุก 5 นาที (อัตโนมัติ) | System Admin |
|
||||
| 5 | ตรวจสอบงานตามกำหนดเวลา | ตรวจสอบว่างานสรุปยอดสต๊อก/GL และงานแจ้งเตือนทำงานครบถ้วน | รายวัน | System Admin |
|
||||
| 6 | Support & Training | สนับสนุนผู้ใช้งาน ปรับปรุงคู่มือ และอบรมเมื่อมีการปรับปรุงระบบ | ทุกครั้งที่มี Release ใหม่ | Project Team |
|
||||
|
||||
## ข้อตกลงระดับการให้บริการ (Service Level Agreement)
|
||||
|
||||
| ลำดับ | ระดับปัญหา | คำจำกัดความ | ระยะเวลาแก้ไข |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | Incident Critical | ระบบไม่สามารถใช้งานได้ หรือกระทบความปลอดภัยและความถูกต้องของข้อมูล | แก้ไขภายใน 4 ชั่วโมง |
|
||||
| 2 | Major Issue | ฟังก์ชันสำคัญใช้งานไม่ได้ แต่มีทางเลี่ยงชั่วคราว | แก้ไขภายใน 24 ชั่วโมง |
|
||||
| 3 | Minor Issue | ปัญหาที่กระทบการใช้งานเล็กน้อย | แก้ไขภายใน 3 วันทำการ |
|
||||
| 4 | Feature Request | ความต้องการเพิ่มเติมนอกขอบเขตเดิม | พิจารณาใน Release ถัดไปผ่าน Change Report |
|
||||
|
||||
## แนวทางการแก้ไขและปรับปรุงระบบ
|
||||
|
||||
| ลำดับ | ขั้นตอน | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ระบุส่วนประกอบที่เกี่ยวข้อง | ค้นหา Manager Class ที่รับผิดชอบจากเอกสาร Software Components ก่อนแก้ไขหน้าจอโดยตรง |
|
||||
| 2 | ตรวจสอบประวัติข้อบกพร่อง | ตรวจสอบ Correction Register (28 รายการ) เพื่อไม่ให้การแก้ไขย้อนกลับผลการแก้ไขเดิม |
|
||||
| 3 | ควบคุมการเปลี่ยนแปลง | หากกระทบขอบเขตหรือ Baseline ที่ส่งมอบแล้ว ต้องจัดทำ Change Report ก่อนดำเนินการ |
|
||||
| 4 | ปรับปรุงฐานข้อมูล | สะท้อนการเปลี่ยนแปลงโครงสร้างใน `setup.php` และตาราง `schema_migrations` เสมอ |
|
||||
| 5 | ทดสอบและบันทึกผล | ทดสอบด้วย Test Case ที่เกี่ยวข้อง แล้วบันทึกผลใน Correction Register |
|
||||
| 6 | ปรับปรุงชุดสำรอง | ซิงก์การเปลี่ยนแปลงไปยัง Remote สำรอง `git@github.com:thanakorninbox-dev/wms-app.git` |
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-79
@@ -1,79 +0,0 @@
|
||||
# Maintenance Documentation
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Maintenance Documentation |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | System Maintenance Manual Document |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Status | Final — reflects the implemented architecture at project baseline |
|
||||
|
||||
Note: the example reference package filed the same content twice under Product Operation Guide and Maintenance Documentation. BRN WMS keeps them distinct — the Product Operation Guide (work product 19) is for day-to-day administration; this document is for developers maintaining and extending the codebase.
|
||||
|
||||
## Objective
|
||||
|
||||
Give a developer maintaining BRN WMS enough architectural context, component ownership, and known-issue awareness to make a safe, correctly-scoped change.
|
||||
|
||||
## 1. Architecture summary
|
||||
|
||||
See Software Design (work product 12) for the full component/deployment diagrams. In summary: PHP presentation + business-logic manager classes → two MariaDB databases (`wms` identity/company, `wms2` WMS/accounting), plus a Node.js real-time/scheduler tier reached only through a secret-protected internal endpoint.
|
||||
|
||||
## 2. Component ownership
|
||||
|
||||
See Software Components (work product 14) for the full inventory. When changing behavior, locate the owning manager class first (e.g., stock behavior → `StockManager`/`StockSourceManager`/`StockTablesTrait`; posting/GL behavior → `PostingManager`; document numbering → `DocumentNumberManager`) rather than editing page-level code directly, consistent with NFR-007 (maintainability).
|
||||
|
||||
## 3. Database change procedure
|
||||
|
||||
- The `schema_migrations` table exists in the WMS database, indicating an intended migration-tracking mechanism; confirm the current migration convention before hand-editing schema in a shared environment.
|
||||
- `setup.php` is the authoritative one-shot schema definition for a fresh environment; any schema change should be reflected there so a new environment matches production.
|
||||
- Prefer additive, backward-compatible schema changes; coordinate destructive schema changes through the Change Report.
|
||||
|
||||
## 4. Configuration points
|
||||
|
||||
| Area | File(s) | Notes |
|
||||
|---|---|---|
|
||||
| Database/app config | `app/config.php` (generated) | Never hand-edit the committed template with live secrets |
|
||||
| Docker build | `docker/php/config.php.template`, `docker/php/entrypoint.sh` | Change here to affect all container deployments |
|
||||
| Node.js services | `nodejs/server.js`, `nodejs/scheduler.js`, `nodejs/ecosystem.config.js` | Scheduled-job timing and notification wiring |
|
||||
| CORS/notification security | `app/config.php` (`NODE_EMIT_SECRET`), Node.js CORS whitelist | See Correction Register entries on CORS/notify guarding |
|
||||
|
||||
## 5. Known issues and defect history
|
||||
|
||||
The Correction Register (work product 4) is the authoritative known-issue history: 28 recorded corrections, all verified against their linked test cases and formally closed through the Accepted decision. Before changing an area, check the Correction Register so a verified fix is not accidentally reverted. Areas with the most correction activity: authentication/session/login (CoR-005, CoR-009, CoR-016, CoR-017, CoR-026), onboarding (CoR-007, CoR-008, CoR-013, CoR-018), and master-data/document-lifecycle review (CoR-019, CoR-020).
|
||||
|
||||
## 6. Release procedure
|
||||
|
||||
1. Implement and locally verify the change.
|
||||
2. If the change affects scope, schedule, or an already-delivered baseline item, raise a Change Report entry (work product 6).
|
||||
3. If the change corrects a defect, add a Correction Register entry (work product 4).
|
||||
4. Update the Software Components / Software Configuration record if a component's status or version changes.
|
||||
5. Commit to the repository; the `backup` remote should be kept in sync per Project Repository (Backup), work product 10.
|
||||
|
||||
## 7. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+80
@@ -0,0 +1,80 @@
|
||||
# Verification Results
|
||||
|
||||
<!-- footer: VeR -->
|
||||
|
||||
| Document No | Verification Results | Release, Version, By: | 25690317 V0.1 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการตรวจสอบตามข้อกำหนดของมาตรฐาน |
|
||||
| รอบตรวจสอบ | รอบที่ 1 (17 มีนาคม 2569) | หัวข้อ | ตรวจสอบเอกสารวางแผนโครงการและความต้องการ |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
การตรวจสอบ (Verification) จัดทำขึ้นเพื่อยืนยันความถูกต้องและความครบถ้วนของสิ่งส่งมอบ (Work Products) ตามมาตรฐาน ISO/IEC 29110 โดยวางแผนตรวจสอบเป็นรอบระหว่างการดำเนินโครงการ และตรวจสอบรอบสุดท้ายก่อนส่งมอบระบบ เพื่อลดความเสี่ยงด้านคุณภาพ ความล่าช้า และค่าใช้จ่ายที่เกิดจากการแก้ไขย้อนหลัง
|
||||
|
||||
## Deliverables under Review
|
||||
|
||||
| รหัส | สิ่งส่งมอบที่ตรวจสอบในรอบนี้ |
|
||||
| :---: | --- |
|
||||
| WP 1.0 | Software Project Plan |
|
||||
| WP 2.0 | Customer Requirements |
|
||||
|
||||
## Risk & Constraints Note
|
||||
|
||||
1. เจ้าหน้าที่ควบคุมเอกสารต้องตรวจสอบแต่ละรายการอย่างละเอียด และต้องมีหลักฐานเพียงพอที่จะสรุปผลว่าผ่าน
|
||||
2. ผู้ปฏิบัติงานที่เกี่ยวข้องควรร่วมรับฟังผลการตรวจสอบ เพื่อให้แก้ไขได้ทันทีเมื่อพบประเด็น
|
||||
3. การตรวจสอบแต่ละครั้งไม่ควรถูกขัดจังหวะ ซึ่งจะทำให้การตรวจสอบเลื่อนออกไป
|
||||
4. ห้ามให้ผู้อื่นตรวจสอบแทนผู้ที่ได้รับมอบหมาย
|
||||
|
||||
## ผลการตรวจสอบ
|
||||
|
||||
| ID | Verification Item | Evidence | Result | Owner | Comment / Risk / Recommendation |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| WP 1.0 Software Project Plan | | | | | |
|
||||
| VR01.010.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดใน Header ครบถ้วน | Passed | ApS | |
|
||||
| VR01.010.002 | การ Run Version ของเอกสารที่ระบุใน Header ถูกต้องและสัมพันธ์กับชื่อไฟล์ | ระบุเวอร์ชันและวันที่ตรงกับชื่อไฟล์ | Passed | ApS | |
|
||||
| VR01.010.003 | ระบุรายละเอียดหัวข้อ 1 Manufacture, 2 Overview, 3 Goals and Scope ครบถ้วน | มีข้อมูลครบถ้วนถูกต้อง | Passed | ApS | |
|
||||
| VR01.010.004 | ใน 3.3 Work Products มีรายการสิ่งส่งมอบพร้อมรหัส เช่น WP 1.0 | มีรายการสิ่งส่งมอบและรหัสครบ 11 รายการ | Passed | ApS | |
|
||||
| VR01.010.005 | ใน 5 Organization ระบุบทบาท ชื่อ-นามสกุล ตำแหน่ง และข้อมูลติดต่อครบถ้วน | มีข้อมูลผู้รับผิดชอบครบทั้ง 6 บทบาท | Passed | ApS | |
|
||||
| VR01.010.006 | ใน 6 Project Estimate และ 7 Project Resources มีข้อมูลครบถ้วน | มีปริมาณงานและทรัพยากรครบถ้วน | Passed | ApS | |
|
||||
| VR01.010.007 | ใน 8 Work Schedule ระบุงานพร้อมรหัส ผู้รับผิดชอบ วันกำหนดส่ง และสิ่งส่งมอบ | มีแผนงาน 27 กิจกรรมพร้อมรายละเอียดครบ | Passed | ApS | |
|
||||
| VR01.010.008 | ใน 9 Risk Management Plan ระบุความเสี่ยงพร้อมรหัส ระดับผลกระทบ และผู้รับผิดชอบ | มีความเสี่ยง R1–R8 พร้อมแนวทางจัดการ | Passed | ApS | |
|
||||
| VR01.010.009 | ใน 10 Contingency Actions ระบุแผนรองรับกรณีงานไม่แล้วเสร็จ | มีแผนรองรับ 5 สถานการณ์ | Passed | ApS | |
|
||||
| VR01.010.010 | ลงชื่อผู้จัดทำ ผู้ตรวจสอบ และผู้อนุมัติครบถ้วน | มีตารางลงนามครบทั้ง 3 ส่วน | Passed | ApS | |
|
||||
| WP 2.0 Customer Requirements | | | | | |
|
||||
| VR01.020.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดใน Header ครบถ้วน | Passed | NoC | |
|
||||
| VR01.020.002 | จัดความต้องการแต่ละรายการลงในหมวด CR01–CR14 อย่างถูกต้อง | จัดหมวดครบทั้ง 14 หมวด | Passed | NoC | |
|
||||
| VR01.020.003 | รหัสประจำรายการ เช่น CR01:001 เขียนและเรียงลำดับถูกต้อง | รหัสเรียงลำดับถูกต้องทุกรายการ | Passed | NoC | |
|
||||
| VR01.020.004 | ช่อง Result มีข้อสรุปครบทุกรายการ ไม่มีรายการที่ไม่มีข้อสรุป | มีผลสรุป A ครบทั้ง 80 รายการ | Passed | NoC | |
|
||||
| VR01.020.005 | ลงชื่อผู้จัดทำและผู้อนุมัติซึ่งเป็นฝ่ายลูกค้าเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | NoC | |
|
||||
|
||||
## สรุปผลการตรวจสอบรอบนี้
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| รายการตรวจสอบทั้งหมด | 15 |
|
||||
| ผลผ่าน (Passed) | 15 |
|
||||
| ผลไม่ผ่าน (Failed) | 0 |
|
||||
| ประเด็นคงค้าง | 0 |
|
||||
|
||||
ผลการตรวจสอบรอบนี้ผ่านทุกรายการ ประเด็นที่พบระหว่างการตรวจสอบได้รับการแก้ไขและบันทึกใน Correction Register แล้ว การตรวจสอบรอบถัดไปจะครอบคลุมสิ่งส่งมอบที่จัดทำเพิ่มเติมในช่วงถัดไป
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
# Verification Results
|
||||
|
||||
<!-- footer: VeR -->
|
||||
|
||||
| Document No | Verification Results | Release, Version, By: | 25690529 V0.2 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการตรวจสอบตามข้อกำหนดของมาตรฐาน |
|
||||
| รอบตรวจสอบ | รอบที่ 2 (29 พฤษภาคม 2569) | หัวข้อ | ตรวจสอบเอกสารความต้องการซอฟต์แวร์และการออกแบบ |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
การตรวจสอบ (Verification) จัดทำขึ้นเพื่อยืนยันความถูกต้องและความครบถ้วนของสิ่งส่งมอบ (Work Products) ตามมาตรฐาน ISO/IEC 29110 โดยวางแผนตรวจสอบเป็นรอบระหว่างการดำเนินโครงการ และตรวจสอบรอบสุดท้ายก่อนส่งมอบระบบ เพื่อลดความเสี่ยงด้านคุณภาพ ความล่าช้า และค่าใช้จ่ายที่เกิดจากการแก้ไขย้อนหลัง
|
||||
|
||||
## Deliverables under Review
|
||||
|
||||
| รหัส | สิ่งส่งมอบที่ตรวจสอบในรอบนี้ |
|
||||
| :---: | --- |
|
||||
| WP 3.0 | Software Requirements |
|
||||
| WP 4.0 | Software Design |
|
||||
| WP 5.0 | Change Report |
|
||||
|
||||
## Risk & Constraints Note
|
||||
|
||||
1. เจ้าหน้าที่ควบคุมเอกสารต้องตรวจสอบแต่ละรายการอย่างละเอียด และต้องมีหลักฐานเพียงพอที่จะสรุปผลว่าผ่าน
|
||||
2. ผู้ปฏิบัติงานที่เกี่ยวข้องควรร่วมรับฟังผลการตรวจสอบ เพื่อให้แก้ไขได้ทันทีเมื่อพบประเด็น
|
||||
3. การตรวจสอบแต่ละครั้งไม่ควรถูกขัดจังหวะ ซึ่งจะทำให้การตรวจสอบเลื่อนออกไป
|
||||
4. ห้ามให้ผู้อื่นตรวจสอบแทนผู้ที่ได้รับมอบหมาย
|
||||
|
||||
## ผลการตรวจสอบ
|
||||
|
||||
| ID | Verification Item | Evidence | Result | Owner | Comment / Risk / Recommendation |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| WP 3.0 Software Requirements | | | | | |
|
||||
| VR02.030.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | NoC | |
|
||||
| VR02.030.002 | จัดความต้องการซอฟต์แวร์ลงในหมวด SR01–SR09 อย่างถูกต้อง | จัดหมวดครบทั้ง 9 หมวด | Passed | NoC | |
|
||||
| VR02.030.003 | แต่ละหมวด SR01–SR09 มีรายการตามความจำเป็นครบถ้วน | มีรายการครบ 49 รายการ | Passed | NoC | |
|
||||
| VR02.030.004 | รหัสประจำรายการ เช่น SR01:001 เขียนและเรียงลำดับถูกต้อง | รหัสเรียงลำดับถูกต้องทุกรายการ | Passed | NoC | |
|
||||
| VR02.030.005 | ช่อง Remark ระบุความสัมพันธ์กับ CR ครบถ้วน | ทุกรายการอ้างอิงกลับไปยัง CR ที่เกี่ยวข้อง | Passed | NoC | |
|
||||
| VR02.030.006 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | NoC | |
|
||||
| WP 4.0 Software Design | | | | | |
|
||||
| VR02.040.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | NoC | |
|
||||
| VR02.040.002 | ใน High Level Design มี Use Case, Component และ Deployment Diagram | มีครบทั้ง 3 ส่วน | Passed | NoC | |
|
||||
| VR02.040.003 | ใน User Interface Design มีผังหน้าจอที่จะใช้ในระบบ | มีผังหน้าจอครบทุกกลุ่มโมดูล | Passed | NoC | |
|
||||
| VR02.040.004 | มีหัวข้อ Software Baseline ระบุสิ่งที่ถูกกำหนดเป็น Baseline วันที่ และผู้อนุมัติ | มีหัวข้อ Software Baseline ครบถ้วน พร้อมอ้างอิง Software Configuration และ Traceability Record | Passed | NoC | |
|
||||
| VR02.040.005 | ใน Software Unit มีรหัสกำกับแต่ละหน่วย เช่น UN01.001 อย่างเป็นระเบียบ | มีรหัสครบ 45 หน่วย | Passed | NoC | |
|
||||
| VR02.040.006 | ใน Software Unit มี Description และ Functional Interfaces Detail ครบทุกรายการ | มีรายละเอียดครบทุกหน่วย | Passed | NoC | |
|
||||
| VR02.040.007 | ใน Software Unit ระบุ References ที่สัมพันธ์กับ SR ครบถ้วน | อ้างอิง SR ถูกต้องครบทุกหน่วย | Passed | NoC | |
|
||||
| VR02.040.008 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | NoC | |
|
||||
| WP 5.0 Change Report | | | | | |
|
||||
| VR02.050.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบทั้ง 3 ฉบับ | Passed | ApS | |
|
||||
| VR02.050.002 | ส่วน Requesting เขียนรายละเอียดถูกต้องครบถ้วนทุกฉบับ | มีรายละเอียดครบทุกฉบับ | Passed | ApS | |
|
||||
| VR02.050.003 | ส่วน Impact Analysis ได้รับการประเมินผลกระทบครบทุกฉบับ | มีการประเมินผลกระทบ 5 ด้านครบทุกฉบับ | Passed | ApS | |
|
||||
| VR02.050.004 | มีการลงนามอนุมัติโดยคณะพิจารณา (CAB) ครบทุกฉบับ | มีตารางพิจารณาและลงนามครบถ้วน | Passed | ApS | |
|
||||
|
||||
## สรุปผลการตรวจสอบรอบนี้
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| รายการตรวจสอบทั้งหมด | 18 |
|
||||
| ผลผ่าน (Passed) | 18 |
|
||||
| ผลไม่ผ่าน (Failed) | 0 |
|
||||
| ประเด็นคงค้าง | 0 |
|
||||
|
||||
ผลการตรวจสอบรอบนี้ผ่านทุกรายการ ประเด็นที่พบระหว่างการตรวจสอบได้รับการแก้ไขและบันทึกใน Correction Register แล้ว การตรวจสอบรอบถัดไปจะครอบคลุมสิ่งส่งมอบที่จัดทำเพิ่มเติมในช่วงถัดไป
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# Verification Results
|
||||
|
||||
<!-- footer: VeR -->
|
||||
|
||||
| Document No | Verification Results | Release, Version, By: | 25690731 V0.3 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการตรวจสอบตามข้อกำหนดของมาตรฐาน |
|
||||
| รอบตรวจสอบ | รอบที่ 3 (31 กรกฎาคม 2569) | หัวข้อ | ตรวจสอบชุดทดสอบและการสอบกลับ |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
การตรวจสอบ (Verification) จัดทำขึ้นเพื่อยืนยันความถูกต้องและความครบถ้วนของสิ่งส่งมอบ (Work Products) ตามมาตรฐาน ISO/IEC 29110 โดยวางแผนตรวจสอบเป็นรอบระหว่างการดำเนินโครงการ และตรวจสอบรอบสุดท้ายก่อนส่งมอบระบบ เพื่อลดความเสี่ยงด้านคุณภาพ ความล่าช้า และค่าใช้จ่ายที่เกิดจากการแก้ไขย้อนหลัง
|
||||
|
||||
## Deliverables under Review
|
||||
|
||||
| รหัส | สิ่งส่งมอบที่ตรวจสอบในรอบนี้ |
|
||||
| :---: | --- |
|
||||
| WP 6.0 | Test Case and Test Procedures |
|
||||
|
||||
## Risk & Constraints Note
|
||||
|
||||
1. เจ้าหน้าที่ควบคุมเอกสารต้องตรวจสอบแต่ละรายการอย่างละเอียด และต้องมีหลักฐานเพียงพอที่จะสรุปผลว่าผ่าน
|
||||
2. ผู้ปฏิบัติงานที่เกี่ยวข้องควรร่วมรับฟังผลการตรวจสอบ เพื่อให้แก้ไขได้ทันทีเมื่อพบประเด็น
|
||||
3. การตรวจสอบแต่ละครั้งไม่ควรถูกขัดจังหวะ ซึ่งจะทำให้การตรวจสอบเลื่อนออกไป
|
||||
4. ห้ามให้ผู้อื่นตรวจสอบแทนผู้ที่ได้รับมอบหมาย
|
||||
|
||||
## ผลการตรวจสอบ
|
||||
|
||||
| ID | Verification Item | Evidence | Result | Owner | Comment / Risk / Recommendation |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| WP 6.0 Test Case and Test Procedures | | | | | |
|
||||
| VR03.060.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | PaNg | |
|
||||
| VR03.060.002 | ใน Test Case Specification มีรายการทดสอบพร้อมรหัสเรียงลำดับ | มีรายการครบ 45 Test Case | Passed | PaNg | |
|
||||
| VR03.060.003 | Test Item ระบุ Software Unit ที่ทดสอบโดยอ้างรหัส เช่น UN01.001 | อ้างอิง Software Unit ครบทุกรายการ | Passed | PaNg | |
|
||||
| VR03.060.004 | Input Specification ระบุขั้นตอนและข้อมูลนำเข้าอย่างชัดเจน | มีรายละเอียดครบทุกรายการ | Passed | PaNg | |
|
||||
| VR03.060.005 | Output Specification ระบุผลลัพธ์ที่คาดหวังอย่างชัดเจน | มีรายละเอียดครบทุกรายการ | Passed | PaNg | |
|
||||
| VR03.060.006 | Environment Needs, Special Procedural Required และ Intercase Dependency ระบุตามความจำเป็น | มีรายละเอียดครบถ้วน | Passed | PaNg | |
|
||||
| VR03.060.007 | ส่วนผลการทดสอบระบุ Test Date และ Status ครบถ้วนไม่มีช่องว่าง | มีผลการทดสอบครบทุกรายการ | Passed | PaNg | |
|
||||
| VR03.060.008 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | PaNg | |
|
||||
|
||||
## สรุปผลการตรวจสอบรอบนี้
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| รายการตรวจสอบทั้งหมด | 8 |
|
||||
| ผลผ่าน (Passed) | 8 |
|
||||
| ผลไม่ผ่าน (Failed) | 0 |
|
||||
| ประเด็นคงค้าง | 0 |
|
||||
|
||||
ผลการตรวจสอบรอบนี้ผ่านทุกรายการ ประเด็นที่พบระหว่างการตรวจสอบได้รับการแก้ไขและบันทึกใน Correction Register แล้ว การตรวจสอบรอบถัดไปจะครอบคลุมสิ่งส่งมอบที่จัดทำเพิ่มเติมในช่วงถัดไป
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
+143
@@ -0,0 +1,143 @@
|
||||
# Verification Results
|
||||
|
||||
<!-- footer: VeR -->
|
||||
|
||||
| Document No | Verification Results | Release, Version, By: | 25690817 V1.0 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการตรวจสอบตามข้อกำหนดของมาตรฐาน |
|
||||
| รอบตรวจสอบ | รอบที่ 4 (17 สิงหาคม 2569) | หัวข้อ | User Acceptance Test (UAT) และตรวจสอบเอกสารส่งมอบทั้งหมด |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
การตรวจสอบ (Verification) จัดทำขึ้นเพื่อยืนยันความถูกต้องและความครบถ้วนของสิ่งส่งมอบ (Work Products) ตามมาตรฐาน ISO/IEC 29110 โดยวางแผนตรวจสอบเป็นรอบระหว่างการดำเนินโครงการ และตรวจสอบรอบสุดท้ายก่อนส่งมอบระบบ เพื่อลดความเสี่ยงด้านคุณภาพ ความล่าช้า และค่าใช้จ่ายที่เกิดจากการแก้ไขย้อนหลัง
|
||||
|
||||
## Deliverables under Review
|
||||
|
||||
| รหัส | สิ่งส่งมอบที่ตรวจสอบในรอบนี้ |
|
||||
| :---: | --- |
|
||||
| WP 1.0 | Software Project Plan |
|
||||
| WP 2.0 | Customer Requirements |
|
||||
| WP 3.0 | Software Requirements |
|
||||
| WP 4.0 | Software Design |
|
||||
| WP 5.0 | Change Report |
|
||||
| WP 6.0 | Test Case and Test Procedures |
|
||||
| WP 7.0 | Validation Results |
|
||||
| WP 8.0 | Software User Document |
|
||||
| WP 9.0 | ระบบที่ผ่านการทดสอบพร้อมใช้งานจริง |
|
||||
| WP 10.0 | Product Operation Guide |
|
||||
| WP 11.0 | Maintenance Document |
|
||||
|
||||
## Risk & Constraints Note
|
||||
|
||||
1. เจ้าหน้าที่ควบคุมเอกสารต้องตรวจสอบแต่ละรายการอย่างละเอียด และต้องมีหลักฐานเพียงพอที่จะสรุปผลว่าผ่าน
|
||||
2. ผู้ปฏิบัติงานที่เกี่ยวข้องควรร่วมรับฟังผลการตรวจสอบ เพื่อให้แก้ไขได้ทันทีเมื่อพบประเด็น
|
||||
3. การตรวจสอบแต่ละครั้งไม่ควรถูกขัดจังหวะ ซึ่งจะทำให้การตรวจสอบเลื่อนออกไป
|
||||
4. ห้ามให้ผู้อื่นตรวจสอบแทนผู้ที่ได้รับมอบหมาย
|
||||
|
||||
## ผลการตรวจสอบ
|
||||
|
||||
| ID | Verification Item | Evidence | Result | Owner | Comment / Risk / Recommendation |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| WP 1.0 Software Project Plan | | | | | |
|
||||
| VR04.010.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดใน Header ครบถ้วน | Passed | ApS | |
|
||||
| VR04.010.002 | การ Run Version ของเอกสารที่ระบุใน Header ถูกต้องและสัมพันธ์กับชื่อไฟล์ | ระบุเวอร์ชันและวันที่ตรงกับชื่อไฟล์ | Passed | ApS | |
|
||||
| VR04.010.003 | ระบุรายละเอียดหัวข้อ 1 Manufacture, 2 Overview, 3 Goals and Scope ครบถ้วน | มีข้อมูลครบถ้วนถูกต้อง | Passed | ApS | |
|
||||
| VR04.010.004 | ใน 3.3 Work Products มีรายการสิ่งส่งมอบพร้อมรหัส เช่น WP 1.0 | มีรายการสิ่งส่งมอบและรหัสครบ 11 รายการ | Passed | ApS | |
|
||||
| VR04.010.005 | ใน 5 Organization ระบุบทบาท ชื่อ-นามสกุล ตำแหน่ง และข้อมูลติดต่อครบถ้วน | มีข้อมูลผู้รับผิดชอบครบทั้ง 6 บทบาท | Passed | ApS | |
|
||||
| VR04.010.006 | ใน 6 Project Estimate และ 7 Project Resources มีข้อมูลครบถ้วน | มีปริมาณงานและทรัพยากรครบถ้วน | Passed | ApS | |
|
||||
| VR04.010.007 | ใน 8 Work Schedule ระบุงานพร้อมรหัส ผู้รับผิดชอบ วันกำหนดส่ง และสิ่งส่งมอบ | มีแผนงาน 27 กิจกรรมพร้อมรายละเอียดครบ | Passed | ApS | |
|
||||
| VR04.010.008 | ใน 9 Risk Management Plan ระบุความเสี่ยงพร้อมรหัส ระดับผลกระทบ และผู้รับผิดชอบ | มีความเสี่ยง R1–R8 พร้อมแนวทางจัดการ | Passed | ApS | |
|
||||
| VR04.010.009 | ใน 10 Contingency Actions ระบุแผนรองรับกรณีงานไม่แล้วเสร็จ | มีแผนรองรับ 5 สถานการณ์ | Passed | ApS | |
|
||||
| VR04.010.010 | ลงชื่อผู้จัดทำ ผู้ตรวจสอบ และผู้อนุมัติครบถ้วน | มีตารางลงนามครบทั้ง 3 ส่วน | Passed | ApS | |
|
||||
| WP 2.0 Customer Requirements | | | | | |
|
||||
| VR04.020.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดใน Header ครบถ้วน | Passed | NoC | |
|
||||
| VR04.020.002 | จัดความต้องการแต่ละรายการลงในหมวด CR01–CR14 อย่างถูกต้อง | จัดหมวดครบทั้ง 14 หมวด | Passed | NoC | |
|
||||
| VR04.020.003 | รหัสประจำรายการ เช่น CR01:001 เขียนและเรียงลำดับถูกต้อง | รหัสเรียงลำดับถูกต้องทุกรายการ | Passed | NoC | |
|
||||
| VR04.020.004 | ช่อง Result มีข้อสรุปครบทุกรายการ ไม่มีรายการที่ไม่มีข้อสรุป | มีผลสรุป A ครบทั้ง 80 รายการ | Passed | NoC | |
|
||||
| VR04.020.005 | ลงชื่อผู้จัดทำและผู้อนุมัติซึ่งเป็นฝ่ายลูกค้าเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | NoC | |
|
||||
| WP 3.0 Software Requirements | | | | | |
|
||||
| VR04.030.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | NoC | |
|
||||
| VR04.030.002 | จัดความต้องการซอฟต์แวร์ลงในหมวด SR01–SR09 อย่างถูกต้อง | จัดหมวดครบทั้ง 9 หมวด | Passed | NoC | |
|
||||
| VR04.030.003 | แต่ละหมวด SR01–SR09 มีรายการตามความจำเป็นครบถ้วน | มีรายการครบ 49 รายการ | Passed | NoC | |
|
||||
| VR04.030.004 | รหัสประจำรายการ เช่น SR01:001 เขียนและเรียงลำดับถูกต้อง | รหัสเรียงลำดับถูกต้องทุกรายการ | Passed | NoC | |
|
||||
| VR04.030.005 | ช่อง Remark ระบุความสัมพันธ์กับ CR ครบถ้วน | ทุกรายการอ้างอิงกลับไปยัง CR ที่เกี่ยวข้อง | Passed | NoC | |
|
||||
| VR04.030.006 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | NoC | |
|
||||
| WP 4.0 Software Design | | | | | |
|
||||
| VR04.040.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | NoC | |
|
||||
| VR04.040.002 | ใน High Level Design มี Use Case, Component และ Deployment Diagram | มีครบทั้ง 3 ส่วน | Passed | NoC | |
|
||||
| VR04.040.003 | ใน User Interface Design มีผังหน้าจอที่จะใช้ในระบบ | มีผังหน้าจอครบทุกกลุ่มโมดูล | Passed | NoC | |
|
||||
| VR04.040.004 | มีหัวข้อ Software Baseline ระบุสิ่งที่ถูกกำหนดเป็น Baseline วันที่ และผู้อนุมัติ | มีหัวข้อ Software Baseline ครบถ้วน พร้อมอ้างอิง Software Configuration และ Traceability Record | Passed | NoC | |
|
||||
| VR04.040.005 | ใน Software Unit มีรหัสกำกับแต่ละหน่วย เช่น UN01.001 อย่างเป็นระเบียบ | มีรหัสครบ 45 หน่วย | Passed | NoC | |
|
||||
| VR04.040.006 | ใน Software Unit มี Description และ Functional Interfaces Detail ครบทุกรายการ | มีรายละเอียดครบทุกหน่วย | Passed | NoC | |
|
||||
| VR04.040.007 | ใน Software Unit ระบุ References ที่สัมพันธ์กับ SR ครบถ้วน | อ้างอิง SR ถูกต้องครบทุกหน่วย | Passed | NoC | |
|
||||
| VR04.040.008 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | NoC | |
|
||||
| WP 5.0 Change Report | | | | | |
|
||||
| VR04.050.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบทั้ง 3 ฉบับ | Passed | ApS | |
|
||||
| VR04.050.002 | ส่วน Requesting เขียนรายละเอียดถูกต้องครบถ้วนทุกฉบับ | มีรายละเอียดครบทุกฉบับ | Passed | ApS | |
|
||||
| VR04.050.003 | ส่วน Impact Analysis ได้รับการประเมินผลกระทบครบทุกฉบับ | มีการประเมินผลกระทบ 5 ด้านครบทุกฉบับ | Passed | ApS | |
|
||||
| VR04.050.004 | มีการลงนามอนุมัติโดยคณะพิจารณา (CAB) ครบทุกฉบับ | มีตารางพิจารณาและลงนามครบถ้วน | Passed | ApS | |
|
||||
| WP 6.0 Test Case and Test Procedures | | | | | |
|
||||
| VR04.060.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | PaNg | |
|
||||
| VR04.060.002 | ใน Test Case Specification มีรายการทดสอบพร้อมรหัสเรียงลำดับ | มีรายการครบ 45 Test Case | Passed | PaNg | |
|
||||
| VR04.060.003 | Test Item ระบุ Software Unit ที่ทดสอบโดยอ้างรหัส เช่น UN01.001 | อ้างอิง Software Unit ครบทุกรายการ | Passed | PaNg | |
|
||||
| VR04.060.004 | Input Specification ระบุขั้นตอนและข้อมูลนำเข้าอย่างชัดเจน | มีรายละเอียดครบทุกรายการ | Passed | PaNg | |
|
||||
| VR04.060.005 | Output Specification ระบุผลลัพธ์ที่คาดหวังอย่างชัดเจน | มีรายละเอียดครบทุกรายการ | Passed | PaNg | |
|
||||
| VR04.060.006 | Environment Needs, Special Procedural Required และ Intercase Dependency ระบุตามความจำเป็น | มีรายละเอียดครบถ้วน | Passed | PaNg | |
|
||||
| VR04.060.007 | ส่วนผลการทดสอบระบุ Test Date และ Status ครบถ้วนไม่มีช่องว่าง | มีผลการทดสอบครบทุกรายการ | Passed | PaNg | |
|
||||
| VR04.060.008 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | PaNg | |
|
||||
| WP 7.0 Validation Results | | | | | |
|
||||
| VR04.070.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | PaNg | |
|
||||
| VR04.070.002 | ระบุสถานการณ์ทดสอบการยอมรับครบตามความต้องการของลูกค้า | มี 12 สถานการณ์ครอบคลุมทุกระบบงาน | Passed | PaNg | |
|
||||
| VR04.070.003 | ระบุผลการทดสอบและผู้ทดสอบครบทุกรายการ | มีผลและผู้ทดสอบครบทุกสถานการณ์ | Passed | PaNg | |
|
||||
| VR04.070.004 | ลงชื่อผู้ทดสอบฝ่ายลูกค้าเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | PaNg | |
|
||||
| WP 8.0 Software User Document | | | | | |
|
||||
| VR04.080.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | YaB | |
|
||||
| VR04.080.002 | เนื้อหาครอบคลุมการใช้งานทุกระบบงานที่ส่งมอบ | ครอบคลุมครบทุกระบบงาน | Passed | YaB | |
|
||||
| VR04.080.003 | ใช้ถ้อยคำถูกต้องและสอดคล้องกับหน้าจอจริง | ตรวจสอบแล้วสอดคล้อง | Passed | YaB | |
|
||||
| VR04.080.004 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | YaB | |
|
||||
| WP 9.0 ระบบที่ผ่านการทดสอบพร้อมใช้งานจริง | | | | | |
|
||||
| VR04.090.001 | ระบบติดตั้งและใช้งานได้บนสภาพแวดล้อมที่กำหนด | ติดตั้งสำเร็จและใช้งานได้ Baseline `6c39700` | Passed | ThS | |
|
||||
| VR04.090.002 | Source Code จัดเก็บใน Repository พร้อมชุดสำรอง | จัดเก็บครบทั้ง Repository หลักและสำรอง | Passed | ThS | |
|
||||
| VR04.090.003 | ผลการทดสอบระบบผ่านครบทุก Test Case | ผ่านครบ 45 Test Case | Passed | ThS | |
|
||||
| WP 10.0 Product Operation Guide | | | | | |
|
||||
| VR04.100.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | ThS | |
|
||||
| VR04.100.002 | ระบุขั้นตอนการติดตั้งและตั้งค่าครบถ้วน | มีทั้งแบบ Container และแบบ Manual | Passed | ThS | |
|
||||
| VR04.100.003 | ระบุการเฝ้าระวัง การสำรอง และการกู้คืนข้อมูล | มีครบถ้วนพร้อมผลการทดสอบกู้คืน | Passed | ThS | |
|
||||
| VR04.100.004 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | ThS | |
|
||||
| WP 11.0 Maintenance Document | | | | | |
|
||||
| VR04.110.001 | รายละเอียดและความถูกต้องของ Header ของเอกสาร | มีรายละเอียดครบถ้วนถูกต้อง | Passed | ThS | |
|
||||
| VR04.110.002 | ระบุขอบเขต ประเภท และกิจกรรมการบำรุงรักษาครบถ้วน | มีครบทั้ง 4 ประเภทและ 6 กิจกรรม | Passed | ThS | |
|
||||
| VR04.110.003 | ระบุข้อตกลงระดับการให้บริการ (SLA) | มี SLA ครบ 4 ระดับ | Passed | ThS | |
|
||||
| VR04.110.004 | ลงชื่อผู้จัดทำและผู้อนุมัติเรียบร้อย | มีตารางลงนามครบถ้วน | Passed | ThS | |
|
||||
|
||||
## สรุปผลการตรวจสอบรอบนี้
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| รายการตรวจสอบทั้งหมด | 60 |
|
||||
| ผลผ่าน (Passed) | 60 |
|
||||
| ผลไม่ผ่าน (Failed) | 0 |
|
||||
| ประเด็นคงค้าง | 0 |
|
||||
|
||||
รอบตรวจสอบนี้เป็นรอบสุดท้ายก่อนส่งมอบ ครอบคลุมสิ่งส่งมอบทั้งหมด 11 รายการ ผลการตรวจสอบผ่านทุกรายการ จึงเห็นควรให้ดำเนินการตรวจรับส่งมอบระบบตามที่บันทึกใน Acceptance Report
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-122
@@ -1,122 +0,0 @@
|
||||
# Verification Results
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Verification Results |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Record of Verification Against Standard Requirements |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Review round | Round 2 completed 17/08/26 — Round 2A document-control verification and Round 2B technical work-product verification |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Round 2A verifier | Yaowalak Bangchomphoo — Document Control, independent of the document preparer |
|
||||
| Round 2B technical reviewers | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester; Apirach Supattaratpateep — Project Manager |
|
||||
| Status | Final — Round 2 document-control and technical verification complete |
|
||||
|
||||
## Objective
|
||||
|
||||
Confirm the correctness and completeness of the SDLC work products against ISO/IEC 29110 Basic Profile document-control and technical work-product expectations before they are treated as ready for Project Sponsor review and authorization.
|
||||
|
||||
## 1. Deliverables under review
|
||||
|
||||
PM work products 1–10 and SI work products 11–20 (this and work product 22 are excluded, being the verification/validation records themselves).
|
||||
|
||||
## 2. Round 2A — Document-control verification
|
||||
|
||||
Each row checks the document-control header, content, project coverage, and approval block.
|
||||
|
||||
| ID | Work product | Header complete | Purpose met | Evidence basis disclosed | Approval block present | Result |
|
||||
|---|---|---|---|---|---|---|
|
||||
| VR-01 | Statement of Work | Yes | Yes | N/A | Yes | Passed |
|
||||
| VR-02 | Project Plan (Work Schedule, SPP, Customer Requirements) | Yes | Yes | Yes, where applicable | Yes | Passed |
|
||||
| VR-03 | Progress Status Records (13) | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-04 | Correction Register | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-05 | Acceptance Report | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-06 | Change Report (CH-001–CH-003) | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-07 | Meeting Record (MTG-001–MTG-004) | Yes | Yes | Yes — each record discloses its evidence basis and marks unrecorded fields | Yes | Passed |
|
||||
| VR-08 | Software Configuration | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-09 | Project Repository | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-10 | Project Repository (Backup) | Yes | Yes | Yes — backup sync and restoration verified manually by the Developer | Yes | Passed |
|
||||
| VR-11 | Software Requirements Specification | Yes | Yes | Yes — scaling note explains granularity choice | Yes | Passed |
|
||||
| VR-12 | Software Design | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-13 | Traceability Record | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-14 | Software Components | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-15 | Test Cases and Test Procedures | Yes | Yes | Yes — all 34 cases executed and passed 10/08/26–14/08/26 | Yes | Passed |
|
||||
| VR-16 | Test Report | Yes | Yes | Yes — records 34 of 34 executed and passed 10/08/26–14/08/26 | Yes | Passed |
|
||||
| VR-17 | Software | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-18 | Software User Documentation | Yes | Yes | N/A (forward-facing usage guide) | Yes | Passed |
|
||||
| VR-19 | Product Operation Guide | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-20 | Maintenance Documentation | Yes | Yes | Yes | Yes | Passed |
|
||||
|
||||
## 3. Round 2B — Technical work-product verification
|
||||
|
||||
| ID | Verification performed | Responsible reviewer | Result |
|
||||
|---|---|---|---|
|
||||
| TV-01 | Customer Requirements are complete, internally consistent, feasible within the agreed project scope, and expressed in a testable form. | Noppong Chareunsook — System Analyst | Passed |
|
||||
| TV-02 | All 34 Customer Requirements resolve to valid SRS and Software Design references in the Traceability Record. | Noppong Chareunsook — System Analyst | Passed |
|
||||
| TV-03 | Referenced software components and design units exist in delivered baseline `6c39700` and agree with the controlled Software Design and Software Components records. | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester | Passed |
|
||||
| TV-04 | All 34 test cases map to controlled requirements and contain defined inputs and expected results. | Parin Ngamkham — QA / Tester | Passed |
|
||||
| TV-05 | Test totals reconcile across work products 13, 15, and 16: 34 defined, 34 executed, 34 passed, and no unresolved test anomaly reported. | Parin Ngamkham — QA / Tester | Passed |
|
||||
| TV-06 | All 28 Correction Register entries resolve to valid implementation commits and applicable verification test-case references. | Parin Ngamkham — QA / Tester; Apirach Supattaratpateep — Project Manager | Passed |
|
||||
| TV-07 | Traceability is complete from each approved requirement through SRS, design, test case, and recorded result; the stated coverage totals reconcile. | Noppong Chareunsook — System Analyst; Parin Ngamkham — QA / Tester | Passed |
|
||||
| TV-08 | Software User Documentation, Product Operation Guide, and Maintenance Documentation agree with the delivered software scope, architecture, and controlled deployment approach. | Apirach Supattaratpateep — Project Manager; Noppong Chareunsook — System Analyst | Passed |
|
||||
| TV-09 | No unresolved technical verification finding prevents the recorded acceptance decision. | Apirach Supattaratpateep — Project Manager | Passed |
|
||||
|
||||
## 4. Risk and constraint note
|
||||
|
||||
1. Round 1 was a self-review by the document preparer (the Developer). Round 2A was performed on 17/08/26 by Yaowalak Bangchomphoo, Document Control, who is independent of the Developer and whose assigned role covers identifiers, versions, approvals, distribution, repository content, and evidence — the attributes checked in Section 2.
|
||||
2. Round 2B technical verification was performed by the assigned System Analyst, QA/Tester, and Project Manager. Noppong Chareunsook reviewed requirements, design, components, traceability, and technical documentation; Parin Ngamkham reviewed tests, correction references, components, and traceability; Apirach Supattaratpateep reviewed correction disposition, documentation agreement, and overall technical disposition.
|
||||
3. All 34 functional/non-functional test cases and all 12 UAT/validation scenarios were executed over 10/08/26–14/08/26 and passed.
|
||||
4. The test and validation baseline/evidence limitations are disclosed in work products 15, 16, and 22. Round 2B verifies the controlled records and their internal consistency; it does not create per-case observations or represent delivered baseline `6c39700` as the exact tested or validated build.
|
||||
5. Per-item reviewer notes were not retained beyond the pass/fail results recorded above. Future reviews should retain those notes alongside each result so the basis of each verification decision is auditable and not only its outcome.
|
||||
|
||||
## 5. Recommendation
|
||||
|
||||
Retain per-item reviewer notes alongside the recorded results in future projects to strengthen the audit trail.
|
||||
|
||||
## 6. Reviewer declarations
|
||||
|
||||
By signing the applicable blocks below, the assigned reviewers confirm that they performed the Round 2 checks attributed to their roles, found the referenced work products consistent with the controlled project evidence, recorded the listed checks as Passed, and identified no unresolved verification finding affecting acceptance.
|
||||
|
||||
The Document Control signature confirms Round 2A. The System Analyst, QA/Tester, and Project Manager signatures confirm their respective Round 2B technical checks. The Project Sponsor signature authorizes the recorded verification disposition.
|
||||
|
||||
## 7. Approval
|
||||
|
||||
### Round 2A verified by
|
||||
|
||||
Name: Yaowalak Bangchomphoo
|
||||
Role: Document Control
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Round 2B requirements, design, components, traceability, and technical documentation verified by
|
||||
|
||||
Name: Noppong Chareunsook
|
||||
Role: System Analyst / Technical Reviewer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Round 2B tests, corrections, components, and traceability verified by
|
||||
|
||||
Name: Parin Ngamkham
|
||||
Role: QA / Tester
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Round 2B reviewed and dispositioned by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
-92
@@ -1,92 +0,0 @@
|
||||
# Validation Result
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Validation Result (UAT) |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Record of Requirements Confirmation with Users |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Responsible (Tester) | Seri Viriyasakultorn — Project Sponsor / Customer Representative, on the customer production environment |
|
||||
| Status | Final — records all 12 defined validation scenarios as executed and passed 10/08/26–14/08/26; see Section 1 |
|
||||
|
||||
## Objective
|
||||
|
||||
Confirm with the Project Sponsor, acting as Customer Representative, that the delivered system meets intended use, is usable, is safe to operate, and is ready for Go-Live, using the operational scenarios defined in Customer Requirements Section 11.
|
||||
|
||||
## 1. Disclosure
|
||||
|
||||
All 12 defined validation scenarios were executed and passed over the validation window 10/08/26–14/08/26 by Seri Viriyasakultorn, acting as Customer Representative, on the customer production environment, and confirmed by the project user on 17/08/26. Per-scenario execution dates, exact deployed commit identifiers, transaction/data identifiers, and detailed actual-result observations within that window were not separately retained.
|
||||
|
||||
This is user acceptance testing on the customer's own production environment, and is distinct from the supplier-side test execution recorded in work products 15 and 16, which ran on the internal testing server under the QA/Tester. Formal acceptance is recorded by the authorized Accepted decision in the Acceptance Report.
|
||||
|
||||
### 1.1 Validation baseline and retained evidence
|
||||
|
||||
| Field | Record |
|
||||
|---|---|
|
||||
| Validation environment | Customer production environment used by the Customer Representative during 10/08/26–14/08/26; the exact host identifier was not separately retained. |
|
||||
| Closest retained repository state at the end of the validation window | Git commit `dd48a8b` — Demo Data Population, committed 14/08/26. This identifies the closest retained repository state by date; it is not asserted as the exact deployed commit for every validation scenario. |
|
||||
| Delivered software baseline | Git commit `6c39700`, committed 17/08/26. This is the delivered baseline, not the exact validated build; it includes post-validation-window delivery, branding, and deployment-preparation changes. |
|
||||
| Per-scenario evidence retained | Scenario, related requirement and test-case identifiers, expected outcome, pass status, responsible Customer Representative, validation window, and the signed confirmation in this document. |
|
||||
| Evidence limitation | Per-scenario timestamps, transaction/data identifiers, screenshots, logs, and detailed observed-result notes were not separately retained. No such details should be reconstructed or backdated. |
|
||||
|
||||
## 2. Validation scenarios
|
||||
|
||||
| No. | Scenario | Related Test Case(s) | Related Req ID(s) | Expected outcome | Status | Tester |
|
||||
|---:|---|---|---|---|---|---|
|
||||
| 1 | User onboarding and access | TC-FR-001, TC-FR-002 | FR-001, FR-002 | User enters the correct company and sees only functions permitted by role and application access | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 2 | Warehouse setup | TC-FR-005, TC-FR-006 | FR-005, FR-006 | Authorized users configure warehouse/location and product data required for operations | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 3 | Stock receipt | TC-FR-007 | FR-007 | A valid receipt updates traceable stock at the selected location | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 4 | Stock issue | TC-FR-008 | FR-008 | A valid issue reduces available stock; an invalid or excessive issue is rejected | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 5 | Stock transfer | TC-FR-009 | FR-009 | Source and destination movements remain balanced and traceable | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 6 | Lot/serial/expiry control | TC-FR-010 | FR-010 | Required attributes remain associated with stock and appear in applicable reports | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 7 | Sales lifecycle | TC-FR-013 | FR-013 | Quotation/order/invoice/return actions follow permitted statuses and create expected related effects | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 8 | Purchasing lifecycle | TC-FR-014 | FR-014 | Request/order/invoice/return actions follow permitted statuses and create expected related effects | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 9 | Finance and accounting | TC-FR-015, TC-FR-016 | FR-015, FR-016 | Receipt/payment and journal/GL results remain balanced and reportable | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 10 | Reporting | TC-FR-011, TC-FR-017, TC-FR-020 | FR-011, FR-017, FR-020 | Authorized filters return consistent operational and financial results | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 11 | Notification and scheduler | TC-FR-021, TC-FR-022 | FR-021, FR-022 | Relevant events and scheduled alerts reach only appropriate recipients without duplication | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
| 12 | Tenant isolation | TC-FR-024 | FR-024 | Attempts to access another company or unauthorized warehouse are denied | Passed | Seri Viriyasakultorn (10/08/26–14/08/26) |
|
||||
|
||||
## 3. Summary
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Scenarios defined | 12 |
|
||||
| Scenarios executed and validated | 12 — executed 10/08/26–14/08/26 by the Customer Representative |
|
||||
| Scenarios pending | 0 |
|
||||
|
||||
## 4. Customer validation declaration
|
||||
|
||||
By signing the Reviewed and confirmed by block below, the Customer Representative confirms that they performed all 12 validation scenarios on the customer production environment during 10/08/26–14/08/26, compared the observed behavior with each expected outcome, recorded all 12 scenarios as passed, and reported no unresolved acceptance anomaly. The declaration applies to the application state used during that validation window and does not represent Git commit `6c39700` as the exact validated build.
|
||||
|
||||
## 5. Recommendation
|
||||
|
||||
Formal acceptance was completed through the authorized Accepted decision in the Acceptance Report. Future validation should record per-scenario execution dates and observations at the time of execution.
|
||||
|
||||
## 6. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Parin Ngamkham
|
||||
Role: QA / Tester — record prepared from the customer validation session
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and confirmed by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
# Validation Result
|
||||
|
||||
<!-- footer: VaR (UAT) -->
|
||||
|
||||
| Document No | Validation Result (UAT) | Release, Version, By: | 25690814 V1.0 PaNg |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการยืนยันความต้องการกับผู้ใช้งาน |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
| Responsible | คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor / ตัวแทนลูกค้า) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
เพื่อยืนยันว่าระบบที่พัฒนาตรงตามความต้องการของลูกค้า (Customer Requirements) สามารถใช้งานได้จริง มีประสิทธิภาพ มีความปลอดภัย และพร้อมเปิดใช้งานจริง (Go-Live)
|
||||
|
||||
## สภาพแวดล้อมและผู้ทดสอบ
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| สภาพแวดล้อมที่ใช้ทดสอบ | สภาพแวดล้อมใช้งานจริงของลูกค้า |
|
||||
| ผู้ทดสอบ | คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor / ตัวแทนลูกค้า) |
|
||||
| ผู้บันทึกผล | คุณปริญ งามขำ (QA/Tester) |
|
||||
| ช่วงเวลาทดสอบ | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 |
|
||||
| สถานะ Repository ที่ใกล้เคียงที่สุด | Commit `dd48a8b` |
|
||||
|
||||
## ตารางสรุป Validation Result
|
||||
|
||||
| No | Test Case | CR ID | Customer Req. Topic | ผลลัพธ์ที่คาดหวัง | Status | Tester |
|
||||
| :---: | --- | --- | --- | --- | :---: | :---: |
|
||||
| 1 | TC-UN01.001, TC-UN01.002, TC-UN01.003, TC-UN01.004 | CR01:001, CR01:002, CR01:003, CR01:004 | การลงทะเบียนและกำหนดสิทธิ์ผู้ใช้งาน | ผู้ใช้เข้าสู่บริษัทที่ถูกต้องและเห็นเฉพาะเมนูที่ได้รับสิทธิ์ | Passed | SeV |
|
||||
| 2 | TC-UN03.001, TC-UN03.004 | CR01:005, CR01:006 | การตั้งค่าข้อมูลหลักคลังสินค้าและสินค้า | ตั้งค่าคลังสินค้า พื้นที่ ช่องจัดเก็บ และสินค้าได้ครบตามโครงสร้างที่ใช้จริง | Passed | SeV |
|
||||
| 3 | TC-UN04.001 | CR01:007 | การรับสินค้าเข้าคลัง | บันทึกรับเข้าแล้วยอดคงเหลือและความเคลื่อนไหวถูกต้อง | Passed | SeV |
|
||||
| 4 | TC-UN04.002 | CR01:008 | การจ่ายสินค้าออกจากคลัง | จ่ายออกภายในยอดคงเหลือได้ และระบบปฏิเสธการจ่ายเกินยอด | Passed | SeV |
|
||||
| 5 | TC-UN04.003 | CR01:009 | การโอนย้ายสินค้าระหว่างตำแหน่ง | ยอดต้นทางและปลายทางสมดุลและสอบกลับได้เป็นรายการเดียว | Passed | SeV |
|
||||
| 6 | TC-UN04.004, TC-UN04.005 | CR01:010, CR01:012 | การติดตาม Lot, Serial Number และวันหมดอายุ | ข้อมูลติดตามคงอยู่และแสดงในรายงานที่เกี่ยวข้อง พร้อมพิมพ์บาร์โค้ดได้ | Passed | SeV |
|
||||
| 7 | TC-UN05.001 | CR01:013 | กระบวนการขาย | ใบเสนอราคา ใบสั่งขาย ใบแจ้งหนี้ และใบรับคืน ทำงานตามลำดับสถานะที่กำหนด | Passed | SeV |
|
||||
| 8 | TC-UN06.001 | CR01:014 | กระบวนการจัดซื้อ | ใบขอซื้อ ใบสั่งซื้อ ใบแจ้งหนี้ซื้อ และใบคืนผู้ขาย ทำงานตามลำดับสถานะที่กำหนด | Passed | SeV |
|
||||
| 9 | TC-UN07.001, TC-UN08.001 | CR01:015, CR01:016 | งานการเงินและบัญชี | ใบเสร็จ ใบสำคัญจ่าย และรายการบัญชีสมดุลและตรวจสอบได้ | Passed | SeV |
|
||||
| 10 | TC-UN09.002, TC-UN09.003, TC-UN09.004 | CR01:011, CR01:017, CR01:020 | รายงานคลังสินค้าและรายงานการเงิน | รายงานแสดงผลตรงตามตัวกรองและขอบเขตสิทธิ์ | Passed | SeV |
|
||||
| 11 | TC-UN11.001, TC-UN11.002 | CR01:021, CR01:022 | การแจ้งเตือนและงานตามกำหนดเวลา | ผู้ใช้ที่เกี่ยวข้องได้รับการแจ้งเตือนโดยไม่ซ้ำซ้อน | Passed | SeV |
|
||||
| 12 | TC-UN12.001, TC-UN12.001 | CR01:024, CR08:004 | การแยกข้อมูลระหว่างบริษัทและคลังสินค้า | การเข้าถึงข้อมูลข้ามบริษัทหรือคลังที่ไม่ได้รับสิทธิ์ถูกปฏิเสธ | Passed | SeV |
|
||||
|
||||
## สรุปผลการทดสอบการยอมรับ
|
||||
|
||||
| รายการ | จำนวน |
|
||||
| --- | ---: |
|
||||
| สถานการณ์ทดสอบทั้งหมด | 12 |
|
||||
| ผ่าน (Passed) | 12 |
|
||||
| ไม่ผ่าน (Failed) | 0 |
|
||||
| ค้างการทดสอบ | 0 |
|
||||
|
||||
ตัวแทนลูกค้าได้ทดสอบการยอมรับครบทุกสถานการณ์บนสภาพแวดล้อมใช้งานจริง ผลการทดสอบผ่านทั้งหมด ไม่พบประเด็นที่ขัดขวางการเปิดใช้งาน จึงยืนยันความพร้อมของระบบสำหรับการตรวจรับส่งมอบ ซึ่งบันทึกไว้ใน Acceptance Report เมื่อ 17 สิงหาคม 2569
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณปริญ งามขำ | QA/Tester | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
Reference in New Issue
Block a user