SDLC docs
This commit is contained in:
Thanakorn
@@ -15,6 +15,4 @@ lib/zxcvbn-php-master/vendor/sebastian/
|
||||
# custom files
|
||||
notes/
|
||||
docs/
|
||||
.claude/
|
||||
SESSION.php
|
||||
sdlc/
|
||||
|
||||
+100
@@ -0,0 +1,100 @@
|
||||
# Statement of Work
|
||||
|
||||
**B.R.N. ENTERPRISE CO., LTD.**
|
||||
1011 Supalai Grand Tower, 7th Floor, Unit 6-7, Rama 3 Road,
|
||||
Chongnonsi, Yannawa, Bangkok 10120
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Statement of Work |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Project name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 05/01/26 V1.0 Final |
|
||||
| Status | Final — ready for authorized approval |
|
||||
|
||||
วันที่ 05/01/26
|
||||
|
||||
**เรื่อง:** ขอบเขตการดำเนินงานโครงการพัฒนาระบบบริหารจัดการคลังสินค้า
|
||||
|
||||
**เรียน:** ผู้บริหารและผู้มีส่วนเกี่ยวข้องในโครงการ
|
||||
|
||||
บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด มีความประสงค์ดำเนินโครงการพัฒนาระบบบริหารจัดการคลังสินค้า เพื่อเพิ่มความถูกต้องและความรวดเร็วของงานคลังสินค้า ทำให้สามารถติดตามสินค้าคงคลัง การเคลื่อนไหวสินค้า คำสั่งซื้อ เอกสารทางธุรกิจ และข้อมูลบัญชีที่เกี่ยวข้องได้อย่างเป็นระบบ โดยใช้ข้อมูลแบบรวมศูนย์และกำหนดสิทธิ์การเข้าถึงตามบทบาทผู้ใช้งาน
|
||||
|
||||
เอกสารฉบับนี้กำหนดขอบเขต ผลส่งมอบ เกณฑ์การยอมรับ หน้าที่ความรับผิดชอบ และกรอบระยะเวลาของโครงการตามแนวทาง ISO/IEC 29110 โดยมีรายละเอียดดังต่อไปนี้
|
||||
|
||||
## 1. วัตถุประสงค์
|
||||
|
||||
- พัฒนาระบบเว็บสำหรับควบคุมสินค้าคงคลังและการปฏิบัติงานคลังสินค้าแบบหลายคลัง
|
||||
- สนับสนุนการรับเข้า เบิกจ่าย โอนย้าย ปรับปรุง และตรวจสอบยอดคงเหลือ พร้อมการติดตาม Lot, Serial Number และวันหมดอายุ
|
||||
- ลดความผิดพลาดจากการทำงานด้วยมือและเพิ่มความสามารถในการตรวจสอบย้อนหลัง
|
||||
- สนับสนุนการบริหารคำสั่งซื้อ จัดซื้อ คืนสินค้า ใบแจ้งหนี้ รายงาน และรายการบัญชีที่เกี่ยวข้อง
|
||||
- จัดให้มีการรักษาความมั่นคงปลอดภัย การแยกข้อมูลรายบริษัท การกำหนดสิทธิ์ และการแจ้งเตือนแบบเรียลไทม์
|
||||
|
||||
## 2. ขอบเขตงาน
|
||||
|
||||
### 2.1 งานวิเคราะห์และออกแบบ
|
||||
|
||||
- รวบรวมและวิเคราะห์ความต้องการของผู้ใช้ กำหนดกระบวนการทำงาน ข้อมูล และกฎทางธุรกิจ
|
||||
- ออกแบบสถาปัตยกรรมระบบ ฐานข้อมูล ส่วนติดต่อผู้ใช้ การเชื่อมต่อบริการ และมาตรการความมั่นคงปลอดภัย
|
||||
|
||||
### 2.2 งานพัฒนาระบบ
|
||||
|
||||
- ข้อมูลหลัก: บริษัท ผู้ใช้ ผู้ติดต่อ สินค้า คลังสินค้า โซน ทางเดิน ตำแหน่งจัดเก็บ และหน่วยนับ
|
||||
- สินค้าคงคลัง: รับเข้า จ่ายออก โอนย้าย ปรับปรุงยอด ตรวจนับ ยอดคงเหลือ และประวัติการเคลื่อนไหว
|
||||
- เอกสารธุรกิจ: Sales Order, Purchase Order, Return, Invoice และลำดับเลขที่เอกสาร
|
||||
- การเงินและบัญชี: รายรับ รายจ่าย สมุดรายวัน รายการบัญชี และรายงานที่ระบบรองรับ
|
||||
- Dashboard, รายงาน, การส่งออกข้อมูล, Barcode/Label และการแนบไฟล์
|
||||
- การยืนยันตัวตน การกำหนดบทบาท Owner/Admin/Staff/Viewer การจำกัดข้อมูลตามบริษัท และการควบคุม session
|
||||
- บริการแจ้งเตือนแบบเรียลไทม์และงานตามกำหนดเวลาด้วย Node.js/Socket.IO
|
||||
|
||||
### 2.3 งานทดสอบและส่งมอบ
|
||||
|
||||
- จัดทำและดำเนินการทดสอบตามความต้องการ บันทึกผล แก้ไขข้อบกพร่อง และทดสอบยืนยันผล
|
||||
- จัดเตรียมคู่มือผู้ใช้ คู่มือการติดตั้ง/ปฏิบัติการ และเอกสารบำรุงรักษา
|
||||
- จัดเตรียมหลักฐานการทวนสอบ การตรวจสอบความใช้ได้ และการยอมรับระบบ
|
||||
|
||||
## 3. ผลส่งมอบ
|
||||
|
||||
ผลส่งมอบประกอบด้วยซอฟต์แวร์ ซอร์สโค้ด สคริปต์การติดตั้งและฐานข้อมูล การกำหนดค่า คู่มือ และ Work Products ของกระบวนการ Project Management และ Software Implementation ตาม ISO/IEC 29110 รวม 22 รายการ โดยจัดเก็บใน Project Repository ภายใต้การควบคุมเวอร์ชัน
|
||||
|
||||
## 4. ข้อยกเว้นและข้อสมมติ
|
||||
|
||||
- ไม่รวมการจัดหาเครื่องแม่ข่าย อุปกรณ์เครือข่าย เครื่องสแกน Barcode หรือบริการจากบุคคลภายนอก เว้นแต่ได้รับอนุมัติเพิ่มเติม
|
||||
- การย้ายข้อมูลเดิม การเชื่อมต่อ ERP/บริการภายนอก และการปรับแต่งนอกขอบเขตต้องผ่านกระบวนการ Change Request
|
||||
- ผู้มีส่วนเกี่ยวข้องต้องให้ข้อมูล ทบทวนเอกสาร และเข้าร่วมการทดสอบ/ยอมรับตามกำหนด
|
||||
|
||||
## 5. แผนงานและจุดควบคุม
|
||||
|
||||
- เริ่มต้นและวางแผนโครงการ: 05/01/26–18/02/26
|
||||
- พัฒนาและทดสอบภายใน: 19/02/26–29/05/26
|
||||
- ทดสอบการยอมรับ จัดทำเอกสาร ส่งมอบ และปรับเสถียรภาพ: 30/05/26–14/08/26
|
||||
- วันเสร็จสิ้นโครงการอย่างเป็นทางการ: 14/08/26
|
||||
|
||||
## 6. เกณฑ์การยอมรับ
|
||||
|
||||
- ฟังก์ชันที่อยู่ในขอบเขตผ่าน Test Cases และเชื่อมโยงกับความต้องการใน Traceability Record
|
||||
- ข้อบกพร่องระดับร้ายแรงที่ขัดขวางการใช้งานได้รับการแก้ไขหรือมีแนวทางที่ผู้มีอำนาจยอมรับ
|
||||
- เอกสารการติดตั้ง การใช้งาน การปฏิบัติการ และการบำรุงรักษาพร้อมใช้งาน
|
||||
- ผลการ Verification, Validation และ Acceptance ได้รับการทบทวนและลงนามโดยผู้มีอำนาจ
|
||||
|
||||
## 7. การบริหารการเปลี่ยนแปลง
|
||||
|
||||
การเปลี่ยนแปลงขอบเขต กำหนดการ หรือผลส่งมอบต้องบันทึกใน Change Report ประเมินผลกระทบ และได้รับอนุมัติก่อนดำเนินการ การแก้ไขข้อบกพร่องให้บันทึกใน Correction Register และเชื่อมโยงกับหลักฐานการทดสอบที่เกี่ยวข้อง
|
||||
|
||||
จึงจัดทำ Statement of Work ฉบับนี้เพื่อใช้เป็นกรอบดำเนินงานและขอให้ผู้เกี่ยวข้องพิจารณาอนุมัติตามอำนาจหน้าที่
|
||||
|
||||
## 8. การอนุมัติ
|
||||
|
||||
**Name:** คุณเสรี วิริยะสกุลธรณ์
|
||||
|
||||
**Project roles:** Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
**Position:** กรรมการผู้จัดการ
|
||||
|
||||
**Company:** บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
|
||||
**Signature:** ______________________________________________
|
||||
|
||||
**Date:** ___________________________________________________
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# Project Repository (Backup)
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Project Repository (Backup) |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกสำรองที่เก็บโครงการ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Record preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
|
||||
| Status | Final — backup existence and sync confirmed by developer statement; independent verification and restoration check remain pending |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This record identifies the backup mechanisms protecting BRN WMS source code and SDLC work products against loss of the primary repository, per the Project Repository record (Section 2).
|
||||
|
||||
## 2. Code backup
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Backup mechanism | Secondary Git remote |
|
||||
| Backup remote name | `backup` |
|
||||
| Backup remote URL | `git@github.com:thanakorninbox-dev/wms-app.git` |
|
||||
| Configured since | Present in repository configuration at report preparation (17/08/26) |
|
||||
| Sync status at report preparation | Reported by the Developer / System Analyst as kept in sync with `origin`/`main` (17/08/26). Not independently technically verified in this session — outbound SSH access to GitHub was unavailable in the working environment (`git@github.com: Permission denied (publickey)`). Developer-reported status is not a substitute for an independently run check (BK-001). |
|
||||
| Restoration check | Not yet performed |
|
||||
|
||||
## 3. Document backup
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Backup mechanism | Exported PDF package, external to the Git repository |
|
||||
| Location | `C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product)` |
|
||||
| Contents | 19 BRN WMS PM work-product PDFs (Statement of Work; Work Schedule; Software Project Plan; Customer Requirements; 13 Progress Status Records; Correction Register; Acceptance Report) |
|
||||
| Verification | Checked as non-empty and readable on 17/08/26 |
|
||||
|
||||
## 4. Outstanding items
|
||||
|
||||
| ID | Item | Owner | Required before |
|
||||
|---|---|---|---|
|
||||
| BK-001 | Independently confirm the `backup` remote is reachable and up to date with `origin`/`main` (`git push backup main` or `git ls-remote backup` or equivalent, from an environment with GitHub credentials) — currently only developer-reported, not independently checked. | Developer / System Analyst | Final acceptance (CON-008) |
|
||||
| BK-002 | Perform and record a restoration check (clone from `backup` and verify integrity). | Developer / System Analyst | Final acceptance (CON-008) |
|
||||
| BK-003 | Export and verify a backup PDF/document package for SI work products once created. | Developer / System Analyst | Final acceptance |
|
||||
|
||||
## 5. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
# Work Schedule
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Work Schedule |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Revised closure target | 24/08/26 — approved through CH-004; original period retained as baseline |
|
||||
| Release | 05/01/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Status | Final — ready for authorized approval |
|
||||
|
||||
## Schedule basis
|
||||
|
||||
The original formal project period is 05/01/26–14/08/26. CH-004, approved on 17/08/26, extends the closure target to 24/08/26 without altering the original baseline. Activities before the first Git commit are reconstructed planning activities based on the agreed lifecycle. Implementation milestones dated 19/02/26–29/05/26 and stabilization activities dated 03/08/26–17/08/26 are supported by Git history.
|
||||
|
||||
| No. | Phase | Task | Details / basis | Responsible role | Start | Finish | Duration | Deliverable / evidence | Status | Remarks |
|
||||
|---|---|---|---|---|---:|---:|---:|---|---|---|
|
||||
| 1.1 | Initiation | Identify project need | Establish the need for centralized warehouse, inventory, order, and accounting control. | Project Sponsor / Project Manager | 05/01/26 | 09/01/26 | 5 days | Statement of Work | Completed | Reconstructed planning activity |
|
||||
| 1.2 | Initiation | Identify stakeholders and objectives | Identify sponsor, operational users, system administrator, development, and approval roles. | Project Manager | 05/01/26 | 16/01/26 | 10 days | Stakeholder and objective records | Completed | Reconstructed planning activity |
|
||||
| 1.3 | Initiation | Approve project scope | Confirm project boundaries, assumptions, deliverables, and acceptance approach. | Project Sponsor | 19/01/26 | 23/01/26 | 5 days | Approved Statement of Work | Pending signature | Authority signature required |
|
||||
| 2.1 | Planning | Collect customer requirements | Document functional, data, security, operational, and quality requirements. | System Analyst / Customer Representatives | 12/01/26 | 06/02/26 | 20 days | Customer Requirements | Completed | Reconstructed from implemented system |
|
||||
| 2.2 | Planning | Prepare Software Project Plan | Define lifecycle, resources, risks, repository, configuration, communication, and controls. | Project Manager | 26/01/26 | 13/02/26 | 15 days | Software Project Plan | Completed | Reconstructed project plan |
|
||||
| 2.3 | Planning | Baseline requirements and schedule | Review initial requirements, priorities, milestones, and work-product responsibilities. | Project Manager / System Analyst | 16/02/26 | 18/02/26 | 3 days | Baseline plan and requirements | Completed | Development begins 19/02/26 |
|
||||
| 3.1 | Execution | Initialize WMS application | Create the initial PHP application repository and baseline structure. | System Analyst / Developer | 19/02/26 | 25/02/26 | 5 days | Git commits `9a50080`–`1843308` | Completed | Git evidenced |
|
||||
| 3.2 | Execution | Security and database foundation | Protect configuration, complete initial security audit actions, and design the stock database. | Developer | 09/03/26 | 17/03/26 | 7 days | Git commits `93d903c`–`a4f474b` | Completed | Git evidenced |
|
||||
| 3.3 | Execution | Inventory and warehouse modules | Implement warehouse capacity, products, storage/bins, lot, serial, expiry, stock movement, and reports. | Developer | 09/04/26 | 29/04/26 | 15 days | Inventory, ICS, dashboard, and report modules | Completed | Git evidenced |
|
||||
| 3.4 | Execution | Authentication and onboarding | Implement login, registration, onboarding, password controls, and role-based access. | Developer | 28/04/26 | 12/05/26 | 11 days | Authentication and user-management modules | Completed | Git evidenced |
|
||||
| 3.5 | Execution | Order and barcode workflows | Implement orders, returns, invoices, switchable warehouse layers, barcode labels, and scanning. | Developer | 02/05/26 | 08/05/26 | 5 days | Order and barcode modules | Completed | Git evidenced |
|
||||
| 3.6 | Execution | Production preparation and setup | Implement dynamic base URL, automated database setup, recovery flow, and production preparation. | Developer | 11/05/26 | 13/05/26 | 3 days | Setup and configuration implementation | Completed | Git evidenced |
|
||||
| 3.7 | Execution | Accounting and finance workflows | Implement chart of accounts, GL, journals, reports, billing, payment, and receipt workflows. | Developer | 13/05/26 | 23/05/26 | 9 days | Accounting and finance modules | Completed | Git evidenced |
|
||||
| 3.8 | Execution | Real-time services and scheduled jobs | Implement Socket.IO notifications, stock/GL aggregates, and operational alerts. | Developer | 22/05/26 | 27/05/26 | 4 days | Node.js service and scheduled jobs | Completed | Git evidenced |
|
||||
| 3.9 | Execution | Security hardening and lifecycle review | Review role guards, tenant scoping, document flows, transaction limits, and corrections. | Developer / Reviewer | 21/05/26 | 28/05/26 | 6 days | Security and lifecycle review commits | Completed | Git evidenced |
|
||||
| 3.10 | Execution | Refactor and development baseline | Remove redundancy and establish the substantially complete development baseline. | Developer | 29/05/26 | 29/05/26 | 1 day | Git commit `a0677d6` | Completed | Development substantially complete |
|
||||
| 4.1 | Control | Maintain progress and meeting records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 14/08/26 | 160 days | Progress Status, Meeting Records, Correction Register | Completed | Records require evidence review |
|
||||
| 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 14/08/26 | 127 days | Git repository and Software Configuration | Completed | Git repository evidenced |
|
||||
| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Overdue / not completed — scheduled period elapsed | Traceability Record complete (34/34 requirements linked); Verification Results is a Round 1 self-review by the document preparer only — independent verification not yet performed |
|
||||
| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed — retrospective user-confirmed execution | All 34 test cases and 12 validation scenarios were retrospectively confirmed as executed and passed on 17/08/26; actual execution dates, environment, and attendees were not separately recorded |
|
||||
| 4.5 | Documentation | Prepare operational documentation | Prepare user, operation, configuration, deployment, and maintenance guidance. | Developer / Document Control | 01/06/26 | 07/08/26 | 50 days | User Documentation, Operation Guide, Maintenance Documentation | Completed | Reconstructed documentation period |
|
||||
| 4.6 | Stabilization | Configuration and login corrections | Correct login and environment configuration issues identified after baseline. | Developer | 03/08/26 | 03/08/26 | 1 day | Git commit `b2c4374` | Completed | Git evidenced |
|
||||
| 4.7 | Stabilization | Prepare demonstration data | Populate controlled demonstration data for validation and handover support. | Developer / Tester | 14/08/26 | 14/08/26 | 1 day | Git commit `dd48a8b` | Completed | Git evidenced |
|
||||
| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed ahead of revised target | Independent verification and review completion confirmed retrospectively by the project user on 17/08/26 |
|
||||
| 5.2 | Closure | Acceptance and project closure | Obtain authorized acceptance and record project closure and follow-up actions. | Project Sponsor / Project Manager | 14/08/26 | 24/08/26 | 11 days | Acceptance Report and closure record | Completed ahead of revised target | Project Sponsor authorization confirmed retrospectively by the project user on 17/08/26; signature capture remains administrative follow-up |
|
||||
|
||||
## Milestones
|
||||
|
||||
| Milestone | Date | Basis |
|
||||
|---|---:|---|
|
||||
| Formal project start | 05/01/26 | Agreed reconstructed project boundary |
|
||||
| Requirements and planning baseline | 18/02/26 | Planned pre-development completion |
|
||||
| Development start | 19/02/26 | First Git commit: `init wms` |
|
||||
| Development substantially complete | 29/05/26 | Final main-development refactoring commit |
|
||||
| Post-development correction | 03/08/26 | Login and configuration correction commit |
|
||||
| Demonstration data and original completion boundary | 14/08/26 | Final repository commit within original baseline |
|
||||
| Revised closure target | 24/08/26 | Approved schedule extension through CH-004 |
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
|
||||
Role: Project Manager / Document Creator
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical contributor
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
|
||||
Role: Developer / System Analyst
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
Position: กรรมการผู้จัดการ
|
||||
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
+414
@@ -0,0 +1,414 @@
|
||||
# Software Project Plan
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Project Plan |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | แผนการดำเนินโครงการพัฒนาระบบบริหารจัดการคลังสินค้า |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 05/01/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Status | Final — ready for review and authorized approval |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This Software Project Plan defines how the BRN WMS project is organized, executed, monitored, controlled, verified, validated, delivered, and closed. It coordinates the Project Management and Software Implementation processes and their 22 work products under ISO/IEC 29110 Basic Profile.
|
||||
|
||||
Pre-development activities dated before the first Git commit are reconstructed planning records. Implementation milestones from 19/02/26 onward are supported by repository history.
|
||||
|
||||
## 2. Project overview
|
||||
|
||||
BRN WMS is a browser-based, multi-company and multi-warehouse management system. It centralizes warehouse master data, inventory movements, sales and purchasing documents, finance and accounting records, reports, access control, and operational notifications.
|
||||
|
||||
The project is intended to:
|
||||
|
||||
- Improve the accuracy and timeliness of warehouse operations.
|
||||
- Provide current stock visibility across authorized warehouses and locations.
|
||||
- Preserve lot, serial-number, expiry-date, and movement traceability.
|
||||
- Control sales, purchasing, return, invoice, receipt, payment, and accounting workflows.
|
||||
- Separate company data and restrict functions according to authorized roles.
|
||||
- Provide management reports, operational alerts, and auditable records.
|
||||
|
||||
## 3. Scope
|
||||
|
||||
### 3.1 Included scope
|
||||
|
||||
- Company, user, role, application-access, SMTP, and system configuration.
|
||||
- Contact, product, category, warehouse, storage-area, and bin master data.
|
||||
- Stock-in, stock-out, stock transfer, balance, lot, serial number, and expiry control.
|
||||
- Warehouse capacity, occupancy, movement, expired-stock, and product-lot reporting.
|
||||
- SKU and warehouse-location barcode labels and supported scanning workflows.
|
||||
- Quotations, sales orders, returns, invoices, and credit notes.
|
||||
- Purchase requests, purchase orders, purchase invoices, and supplier returns.
|
||||
- Receipt billing, receipts, payment billing, and payments.
|
||||
- Chart of accounts, departments, journals, general ledger, formulas, and financial reports.
|
||||
- Controlled document numbering and lifecycle/status handling.
|
||||
- Real-time notifications using Node.js and Socket.IO.
|
||||
- Scheduled stock/GL maintenance, low-stock alerts, and overdue-invoice alerts.
|
||||
- Deployment configuration, database setup, operating guidance, and maintenance information.
|
||||
- ISO/IEC 29110 work products and controlled project repository.
|
||||
|
||||
### 3.2 Excluded scope
|
||||
|
||||
- Procurement of servers, networks, barcode scanners, printers, or user devices.
|
||||
- Legacy-data migration unless separately assessed and approved.
|
||||
- Integration with external ERP, banking, shipping, tax, or third-party services unless approved through change control.
|
||||
- Custom functionality outside the baselined requirements.
|
||||
- Production hosting or third-party subscription fees unless separately authorized.
|
||||
|
||||
## 4. Objectives and success criteria
|
||||
|
||||
The project is successful when:
|
||||
|
||||
- All acceptance-critical requirements are implemented and traceable to verification evidence.
|
||||
- Representative warehouse, sales, purchasing, finance, and accounting workflows pass validation.
|
||||
- No unresolved critical defect blocks intended operation or compromises security or data integrity.
|
||||
- Installation, configuration, user, operation, and maintenance documentation is available.
|
||||
- Software and controlled work products are stored in the project repository.
|
||||
- Verification, validation, and acceptance records receive the required review and authorization.
|
||||
|
||||
## 5. Lifecycle and schedule
|
||||
|
||||
| Phase | Period | Main activities | Primary outputs |
|
||||
|---|---:|---|---|
|
||||
| Initiation | 05/01/26–23/01/26 | Establish need, stakeholders, objectives, scope, and authority. | Statement of Work, stakeholder records |
|
||||
| Planning | 12/01/26–18/02/26 | Collect requirements; define schedule, resources, risks, controls, and baselines. | Customer Requirements, Work Schedule, Software Project Plan |
|
||||
| Implementation | 19/02/26–29/05/26 | Analyze, design, code, configure, integrate, review, and test the system. | SRS, Software Design, Components, Test Cases, Software |
|
||||
| Verification and validation | 30/05/26–07/08/26 | Review work products and validate representative operational workflows. | Traceability, Test Report, Verification and Validation Results |
|
||||
| Documentation and stabilization | 01/06/26–14/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
|
||||
| Closure | 10/08/26–14/08/26 | Review repository, resolve open actions, obtain acceptance, and close the project. | Acceptance Report, List of Evidence, repository baseline |
|
||||
|
||||
Detailed activities and evidence are maintained in the Work Schedule.
|
||||
|
||||
## 6. Software development lifecycle methodology
|
||||
|
||||
The example reference package states a Waterfall model. BRN WMS does not state the same model, because Git evidence does not support it — the commit history shows continuous, incremental delivery (individual features, modules, and security corrections landing throughout the implementation period, interleaved rather than separated into discrete sequential phases; see the Correction Register for 29 examples of hardening applied alongside ongoing feature work, not after a distinct "testing phase"). Restating "Waterfall" here would misrepresent the actual evidence.
|
||||
|
||||
BRN WMS is more accurately described as **incremental/evolutionary**, within the same overall lifecycle stages used for planning and reporting purposes (Section 5):
|
||||
|
||||
| Stage | How it was actually approached |
|
||||
|---|---|
|
||||
| Requirements | Captured once at a reconstructed level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
|
||||
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was reconstructed from the as-built architecture, not authored before coding began |
|
||||
| Implementation | Continuous, feature-by-feature, evidenced by 105 commits across the implementation period with no clean phase boundary between "build" and "test/fix" |
|
||||
| Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal independent verification remains a separate, not-yet-executed activity (work product 21) |
|
||||
| Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |
|
||||
|
||||
This is disclosed as a characterization of *how the work actually happened*, reconstructed from Git evidence — not a methodology that was chosen and documented in advance, since no contemporaneous methodology decision record exists.
|
||||
|
||||
## 7. Organization and responsibilities
|
||||
|
||||
| Role | Assigned person | Responsibilities |
|
||||
|---|---|---|
|
||||
| Project Sponsor / Customer Representative / Authorized Approver | คุณเสรี วิริยะสกุลธรณ์ | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล | Analyze requirements; design, implement, configure, correct, and maintain technical records and source code, aligned with Git implementation evidence. |
|
||||
| Tester / Reviewer | ปริญ งามขำ | Prepare and execute tests, review work products, report defects, and confirm corrections. |
|
||||
| Document Control | คุณเยาวลักษณ์ บางชมภู | Control identifiers, versions, approvals, distribution, repository content, and evidence. |
|
||||
|
||||
One person may perform more than one operational role when independence is not mandatory. Approval authority must remain with the designated authorized approver or a formally delegated authority.
|
||||
|
||||
## 8. Resources and environment
|
||||
|
||||
### 8.1 Human resources and effort estimate
|
||||
|
||||
The example reference package's Software Project Plan includes a "Project Estimate" section with work-product size and a Effort Man-Day table per role. BRN WMS reconstructs the resource picture differently, for a reason that must stay explicit: no contemporaneous time-tracking record (hours or person-days actually worked) exists for this project, so a man-day effort table cannot be produced without fabricating numbers. What follows is limited to what is actually evidenced.
|
||||
|
||||
**Headcount** (matches the Organization and responsibilities table in Section 6 — one person per role, not a multi-person team per role as in the example):
|
||||
|
||||
| Role | Headcount |
|
||||
|---|---:|
|
||||
| Project Sponsor | 1 |
|
||||
| Project Manager | 1 |
|
||||
| Developer / System Analyst | 1 |
|
||||
| Tester / Reviewer | 1 |
|
||||
| Document Control | 1 |
|
||||
|
||||
**Calendar duration by phase** (reconstructed from Git evidence and the agreed lifecycle; phases overlap toward the end of the project rather than running strictly sequentially — see Section 5 for the phase table and the Work Schedule for per-task duration):
|
||||
|
||||
| Phase | Calendar span | Approx. duration |
|
||||
|---|---|---:|
|
||||
| Initiation | 05/01/26–23/01/26 | 19 days |
|
||||
| Planning | 12/01/26–18/02/26 | 38 days |
|
||||
| Implementation | 19/02/26–29/05/26 | 100 days |
|
||||
| Verification and validation | 30/05/26–07/08/26 | 70 days |
|
||||
| Documentation and stabilization | 01/06/26–14/08/26 | 75 days |
|
||||
| Closure | 10/08/26–14/08/26 | 5 days |
|
||||
|
||||
These are calendar spans, not effort (person-days actually worked) — the two are not the same thing, and only the former is evidenced (by the agreed lifecycle and Git commit dates). No effort/man-day figure is stated because none is evidenced; this is a deliberate omission, not an oversight.
|
||||
|
||||
### 8.2 Software and infrastructure
|
||||
|
||||
- PHP 8.0 or later.
|
||||
- MySQL or MariaDB.
|
||||
- Nginx or another compatible PHP web server.
|
||||
- Node.js, npm, Socket.IO, and PM2 for real-time and scheduled services.
|
||||
- Git repository with `main` as the controlled integration baseline.
|
||||
- Current standards-based desktop and mobile browsers.
|
||||
- Asia/Bangkok time zone across application and scheduled-job environments.
|
||||
|
||||
### 8.3 Logical application components
|
||||
|
||||
| Component | Purpose |
|
||||
|---|---|
|
||||
| PHP web application | Main user interface and operational APIs |
|
||||
| Identity/company database | Users, companies, access, SMTP, usage, and related configuration |
|
||||
| WMS/accounting database | Warehouse, inventory, documents, finance, and accounting records |
|
||||
| Node.js notification service | Browser notifications and application event relay |
|
||||
| Node.js scheduler | Aggregate maintenance and scheduled operational alerts |
|
||||
|
||||
### 8.4 Configuration constraints
|
||||
|
||||
- Local configuration and secrets must not be committed to Git.
|
||||
- Production database credentials must use the minimum privileges required after installation.
|
||||
- Application, database, upload, and service configuration must follow the controlled configuration guide.
|
||||
- Public access to source-control metadata, secrets, and internal service endpoints must be restricted.
|
||||
|
||||
### 8.5 Computer and equipment resources
|
||||
|
||||
The example reference package's Section 7 lists specific equipment (notebook count, scanner, Git server, software licenses). No equipment inventory record exists as project evidence for BRN WMS — this is not fabricated here. What is evidenced instead:
|
||||
|
||||
| Item | Evidence |
|
||||
|---|---|
|
||||
| Git hosting | Primary remote `origin` (`188.166.228.62:nok/wms-app.git`) and backup remote `backup` (GitHub) — see Project Repository, work product 9 |
|
||||
| Deployment target | Manual LAMP install or Docker Compose stack (`php-apache`, `mariadb`, `node/pm2`) — see Software Configuration, work product 8, and Product Operation Guide, work product 19 |
|
||||
| Developer workstation(s) | Not recorded — no inventory evidence exists |
|
||||
| Office/licensed software (word processor, spreadsheet, etc.) | Not recorded — no inventory evidence exists |
|
||||
|
||||
## 9. Deliverables and work products
|
||||
|
||||
### 9.1 Project Management work products
|
||||
|
||||
1. Statement of Work
|
||||
2. Project Plan, including Work Schedule, Software Project Plan, and Customer Requirements
|
||||
3. Progress Status Record
|
||||
4. Correction Register
|
||||
5. Acceptance Report
|
||||
6. Change Report
|
||||
7. Meeting Record
|
||||
8. Software Configuration
|
||||
9. Project Repository
|
||||
10. Project Repository Backup
|
||||
|
||||
### 9.2 Software Implementation work products
|
||||
|
||||
11. Software Requirements Specification
|
||||
12. Software Design
|
||||
13. Traceability Record
|
||||
14. Software Components
|
||||
15. Test Cases and Test Procedures
|
||||
16. Test Report
|
||||
17. Software
|
||||
18. Software User Documentation
|
||||
19. Product Operation Guide
|
||||
20. Maintenance Documentation
|
||||
21. Verification Results
|
||||
22. Validation Results
|
||||
|
||||
## 10. Monitoring and communication
|
||||
|
||||
| Record or activity | Frequency or trigger | Owner | Audience |
|
||||
|---|---|---|---|
|
||||
| Work Schedule update | At least weekly during active work | Project Manager | Project team and sponsor |
|
||||
| Progress Status Record | Weekly during active work | Project Manager | Project team and sponsor |
|
||||
| Project meeting | At planned reviews or when decisions are required | Project Manager | Relevant stakeholders |
|
||||
| Meeting Record | For each formal project/review meeting | Recorder | Attendees and affected stakeholders |
|
||||
| Correction Register | When a defect, issue, or nonconformity is identified | Tester / Project Manager | Assigned owner and reviewer |
|
||||
| Change Report | When a baseline change is requested | Project Manager | Sponsor, affected team, customer representative |
|
||||
| Repository review | At each baseline and project closure | Document Control | Project Manager and reviewer |
|
||||
|
||||
Progress status includes completed work, planned work, deviations, risks, issues, required decisions, corrective actions, and schedule impact.
|
||||
|
||||
## 11. Risk management
|
||||
|
||||
| ID | Risk | Impact | Planned response / control | Owner |
|
||||
|---|---|---|---|---|
|
||||
| R-01 | Pre-development records are reconstructed | Audit evidence may be weaker than contemporaneous records. | Mark assumptions clearly and obtain retrospective review and approval. | Project Manager |
|
||||
| R-02 | Unauthorized access or cross-company data exposure | Confidentiality and integrity failure. | Server-side role guards, company/warehouse scoping, session controls, and security review. | Developer / Reviewer |
|
||||
| R-03 | Incorrect inventory balance | Operational and financial records become unreliable. | Transactions, input validation, locking, approval flow, reconciliation, and movement tests. | Developer / Tester |
|
||||
| R-04 | Secret or configuration exposure | System compromise or service interruption. | Ignore local secrets, provide templates, restrict web access, and review deployment configuration. | Configuration Manager |
|
||||
| R-05 | Incomplete requirement or acceptance evidence | Delivery cannot be objectively demonstrated. | Maintain bidirectional traceability and obtain signatures before baselining. | Project Manager |
|
||||
| R-06 | Uncontrolled scope expansion | Schedule and quality degradation. | Require Change Report, impact analysis, authorization, and re-planning. | Project Manager / Sponsor |
|
||||
| R-07 | Inadequate backup or recovery | Loss of source, documents, or operational data. | Maintain repository backup and documented database/file backup and recovery procedures. | Configuration Manager |
|
||||
| R-08 | Third-party or environment incompatibility | Deployment or notification failure. | Document supported versions and verify the target environment before acceptance. | Developer / System Administrator |
|
||||
|
||||
Risks are reviewed with progress status. New risks and changes to exposure or response are recorded by the Project Manager.
|
||||
|
||||
### 11.1 Contingency actions for non-completed tasks
|
||||
|
||||
Distinct from the risk table above (which addresses project-level threats), this table addresses the specific, recurring situation of an individual task or work product not finishing by its planned date.
|
||||
|
||||
| Situation | Common cause | Likely impact | Contingency action | Owner |
|
||||
|---|---|---|---|---|
|
||||
| Task not finished by its due date | Timeline or resource estimate was too tight | Downstream tasks slip; delivery date at risk | Meet with the team to reassess status and priority; agree and communicate a revised timeline | Project Manager |
|
||||
| Delay due to insufficient staffing (illness, unavailability) | Single-person roles (Section 7) have no backup | Work stalls until the person returns | Document a handover/knowledge-transfer note; consider temporary outside help for the specific gap only with Sponsor authorization | Project Manager |
|
||||
| Delay due to late or incomplete requirement/content input | Upstream dependency (customer input, data) not ready | Downstream development or testing cannot proceed | Escalate to the Sponsor with a clear description of what is blocking; agree a revised input date | Project Manager |
|
||||
| Delay due to unexpected technical complexity | Underestimated integration/defect complexity discovered during work | Task takes materially longer than planned | Prioritize by severity (Critical/High/Low, per Section 12.1); temporarily set aside lower-priority items | Developer |
|
||||
| Delay because scope changed mid-task | Requirement changed after work started | Effort already spent may be partially invalidated | Raise a Change Report; obtain authorization before continuing under the new scope | Project Manager |
|
||||
|
||||
## 12. Quality assurance
|
||||
|
||||
- Assign a unique identifier to each approved requirement.
|
||||
- Review requirements for clarity, completeness, consistency, testability, and scope alignment.
|
||||
- Review design against requirements and operational constraints.
|
||||
- Review implementation for authorization, tenant isolation, data integrity, configuration safety, and error handling.
|
||||
- Trace requirements to design elements, components, test cases, and results.
|
||||
- Record defects and nonconformities in the Correction Register.
|
||||
- Re-test corrected behavior and retain objective evidence.
|
||||
- Validate representative end-to-end scenarios with customer-oriented data.
|
||||
|
||||
### 12.1 Defect disposition
|
||||
|
||||
| Severity | Meaning | Acceptance treatment |
|
||||
|---|---|---|
|
||||
| Critical | Prevents core operation, compromises security, causes cross-company exposure, or corrupts essential data. | Must be corrected and verified before acceptance. |
|
||||
| Major | Material function fails without an acceptable workaround. | Correct before acceptance or obtain explicit authorized disposition. |
|
||||
| Minor | Limited impact with an acceptable workaround. | Record planned correction or authorized acceptance. |
|
||||
| Observation | Improvement or documentation item without functional failure. | Record and prioritize as appropriate. |
|
||||
|
||||
### 12.2 Quality criteria and evaluation methods
|
||||
|
||||
The example reference package states measurable quality thresholds directly in the Software Project Plan (response time, uptime, security scan result, etc.). BRN WMS's measurable criteria are already defined as non-functional requirements in Customer Requirements (Section 8) and restated as technical requirements in the SRS (work product 11); this table cross-references them here rather than duplicating a second copy that could drift out of sync.
|
||||
|
||||
| Quality area | Criterion | Evaluation method | Reference |
|
||||
|---|---|---|---|
|
||||
| Functional correctness | All Must requirements implemented and traceable | Traceability Record review + Test Report execution | NFR-009, work products 13, 16 |
|
||||
| Performance | Practical operational response time; aggregates support dashboards/reports | Representative-operation timing under agreed data volume | NFR-006, SR05:001–003, TC-NFR-006 |
|
||||
| Security | No unresolved critical security defect; server-side auth/tenant scope enforced | Negative-authorization/invalid-input testing | NFR-002, SR07:001–005, TC-NFR-002 |
|
||||
| Reliability/integrity | No invalid negative/duplicate stock or GL movement | Failure/rollback and concurrency test | NFR-003, SR09:003, TC-NFR-003 |
|
||||
| Usability | Responsive UI usable on desktop and warehouse-floor devices | Representative-screen check at agreed viewport sizes | NFR-005, SR02:002, TC-NFR-005 |
|
||||
| Installability | Installation/configuration/backup/recovery repeatable | Follow Product Operation Guide end-to-end | NFR-004, TC-NFR-004 |
|
||||
| Post-delivery support | Backup and restoration | Restoration check (currently open — BK-002) | Project Repository (Backup), work product 10 |
|
||||
|
||||
None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed (user-confirmed) and 12 of 12 passed (user-confirmed) (see the Acceptance Report's current-status note).
|
||||
|
||||
## 13. Verification and validation
|
||||
|
||||
Verification confirms that each work product satisfies its specified inputs and criteria. Validation confirms that the integrated BRN WMS supports its intended operational use.
|
||||
|
||||
Verification covers:
|
||||
|
||||
- Customer Requirements and Software Requirements Specification.
|
||||
- Software Design and database/configuration design.
|
||||
- Software Components and integration behavior.
|
||||
- Test Cases, Test Procedures, Test Report, and traceability.
|
||||
- User, operation, configuration, and maintenance documentation.
|
||||
|
||||
Validation covers representative workflows for:
|
||||
|
||||
- User onboarding and role-based access.
|
||||
- Warehouse and product configuration.
|
||||
- Stock receipt, issue, transfer, balance, lot, serial, and expiry handling.
|
||||
- Sales, purchasing, return, invoice, receipt, and payment workflows.
|
||||
- Accounting postings and management reports.
|
||||
- Notifications, scheduled jobs, and operational recovery.
|
||||
|
||||
## 14. Configuration management
|
||||
|
||||
Configuration items include:
|
||||
|
||||
- PHP, JavaScript, CSS, Node.js, and database/setup source files.
|
||||
- Application and service configuration templates.
|
||||
- Database schema and migration/setup logic.
|
||||
- Controlled requirements, design, test, guide, and management work products.
|
||||
- Approved releases, evidence, and repository backups.
|
||||
|
||||
Controls include:
|
||||
|
||||
- Git history and the controlled `main` baseline.
|
||||
- Project-code-based filenames and document version/status identifiers.
|
||||
- Review and authorization before changing an approved baseline.
|
||||
- Exclusion of passwords, tokens, local configuration, logs, uploads, and generated secrets from source control.
|
||||
- Repository and operational-data backup with recoverability checks.
|
||||
|
||||
## 15. Change and correction control
|
||||
|
||||
A baseline change follows this sequence:
|
||||
|
||||
1. Record the requested change and reason.
|
||||
2. Analyze its scope, schedule, technical, quality, security, and documentation impact.
|
||||
3. Obtain authorization from the designated authority.
|
||||
4. Update affected plans, requirements, design, traceability, tests, and configuration records.
|
||||
5. Implement and verify the change.
|
||||
6. Record the result and close the Change Report.
|
||||
|
||||
Defects and nonconformities are recorded in the Correction Register, assigned to an owner, corrected, re-tested, and closed with evidence.
|
||||
|
||||
## 16. Repository and document control
|
||||
|
||||
### 16.1 File naming convention
|
||||
|
||||
BRN WMS's actual naming convention, in force since PM work product 1 and used consistently across all 42 controlled files, differs deliberately from the example reference project's:
|
||||
|
||||
`[Project code] [Document name] [YYYYMMDD Buddhist] V[version]`, for example `200-WMS-26-001-00 Correction Register 25690817 V1.0`.
|
||||
|
||||
| Element | Meaning | Example |
|
||||
|---|---|---|
|
||||
| Project code | `200-WMS-26-001-00` | Fixed |
|
||||
| Document name | Descriptive title; where a work product has multiple instances (Progress Status Record, Change Report, Meeting Record), a short distinguishing suffix is added | `- Rack to Bin Rename` |
|
||||
| Date | Compact Buddhist-calendar date (`YYYYMMDD`), matching the date on the document header | `25690817` |
|
||||
| Version | `V<major>.<minor>`, e.g. `V1.0` | `V1.0` |
|
||||
|
||||
**Deviation from the example, stated explicitly:** the example appends the author's initials to the filename (e.g., `...V1.0 ApS.pdf`); BRN WMS does **not** append author initials, per an explicit project decision recorded in `SDLC_DOCS.md`.
|
||||
|
||||
### 16.2 Version declaration
|
||||
|
||||
Documents created for BRN WMS are released directly at `V1.0` once content is complete, without the example's separate `0.1`/`0.2` Draft stages — BRN WMS work products are not labeled `Draft` unless explicitly requested, per the same recorded decision. "Final" in the document-control Status field means the content is complete and ready for review, not that an authority has signed it — see each document's own Approval section and the Acceptance Report's current-status note for actual signature status.
|
||||
|
||||
### 16.3 Repository and backup
|
||||
|
||||
- Every controlled filename starts with `200-WMS-26-001-00`.
|
||||
- Documents identify title, date, version, status, preparer, reviewer, and approver as applicable.
|
||||
- Drafts remain distinguishable from approved baselines.
|
||||
- The Project Repository contains the current controlled work products and supporting evidence (work product 9).
|
||||
- The repository backup is maintained separately and checked during project closure (work product 10); as of this Software Project Plan's last refresh, that check remains open (BK-001, BK-002).
|
||||
- Superseded records are retained or archived according to organizational control practices.
|
||||
|
||||
## 17. Acceptance and closure
|
||||
|
||||
The project may close when:
|
||||
|
||||
- Acceptance-critical requirements have passed their linked verification and validation.
|
||||
- No unresolved critical defect remains.
|
||||
- Deferred items and accepted exceptions have authorized dispositions.
|
||||
- Required user, operation, configuration, and maintenance documents are available.
|
||||
- Software, source, setup information, evidence, and required work products are in the repository.
|
||||
- The Acceptance Report and closure decision are signed by the authorized approver.
|
||||
|
||||
## 18. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
|
||||
Role: Project Manager
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical contributor
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
|
||||
Role: Developer / System Analyst
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
Position: กรรมการผู้จัดการ
|
||||
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
+274
@@ -0,0 +1,274 @@
|
||||
# Customer Requirements
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Customer Requirements |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารบันทึกและสรุปความต้องการของลูกค้า |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 12/01/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
|
||||
| Status | Final — ready for review and authorized approval |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document records the customer-level functional and non-functional requirements for BRN WMS. It provides the approved input for the Software Requirements Specification, Software Design, Traceability Record, Test Cases and Test Procedures, Verification Results, Validation Results, and Acceptance Report.
|
||||
|
||||
The requirements were reconstructed from the agreed project scope, implemented source code, database structure, configuration, and Git history. The Developer/System Analyst records the technical interpretation, and the Project Sponsor acting as Customer Representative reviews the operational accuracy and authorizes the baseline.
|
||||
|
||||
## 2. Business need
|
||||
|
||||
B.R.N. Enterprise Co., Ltd. requires a centralized warehouse management system to improve inventory accuracy, transaction control, operational visibility, and auditability. The system must support multiple companies and warehouses while restricting users to authorized data and functions.
|
||||
|
||||
The expected business outcomes are:
|
||||
|
||||
- Timely and accurate stock information.
|
||||
- Traceable receipts, issues, transfers, lots, serial numbers, and expiry dates.
|
||||
- Controlled sales, purchasing, finance, and accounting documents.
|
||||
- Reduced manual error and duplicate data handling.
|
||||
- Faster operational and management reporting.
|
||||
- Stronger access control, company-data isolation, and accountability.
|
||||
- Maintainable deployment, configuration, backup, and recovery procedures.
|
||||
|
||||
## 3. Stakeholders
|
||||
|
||||
| Stakeholder | Project role | Responsibility and interest |
|
||||
|---|---|---|
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Customer Representative / Authorized Approver | Represent customer needs and approve project scope, strategic decisions, requirement baseline, acceptance, and closure. |
|
||||
| คุณอภิรัชต์ สุภัทรประทีป | Project Manager | Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline. |
|
||||
| ธนกร สถิตวิทยากุล | Developer / System Analyst | Analyze customer needs, specify system behavior, design and implement the solution, and maintain technical traceability aligned with Git evidence. |
|
||||
| ปริญ งามขำ | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer; added to the project 17/08/26. |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; added to the project 17/08/26, same role as the example reference project for the same company. |
|
||||
| Warehouse Manager and Staff | Operational users | Perform and review warehouse, stock, barcode, and reporting operations. |
|
||||
| Sales and Purchasing Users | Business users | Perform quotation, order, purchase, invoice, and return workflows. |
|
||||
| Finance and Accounting Users | Business users | Perform billing, receipt, payment, journal, ledger, and financial reporting activities. |
|
||||
| System Administrator | Supporting user | Configure the environment, company, users, services, monitoring, backup, and recovery. |
|
||||
| Management / Auditor | Information consumer | Review controlled records, transaction history, exceptions, and management information. |
|
||||
|
||||
## 4. Operational context
|
||||
|
||||
BRN WMS is a browser-based application composed of:
|
||||
|
||||
- A PHP web application providing user interfaces and operational APIs.
|
||||
- A MySQL/MariaDB identity and company database.
|
||||
- A MySQL/MariaDB WMS and accounting database.
|
||||
- A Node.js/Socket.IO service for real-time notifications.
|
||||
- A Node.js scheduler for aggregate maintenance and operational alerts.
|
||||
- A controlled Git repository for source and configuration templates.
|
||||
|
||||
Users access the system through current standards-based browsers. The application and scheduled services operate using the Asia/Bangkok time zone.
|
||||
|
||||
## 5. Assumptions and constraints
|
||||
|
||||
- The application is deployed in a controlled PHP 8+, MySQL/MariaDB, and Node.js environment.
|
||||
- B.R.N. provides authorized users, representative operational data, and availability for review and validation.
|
||||
- Required network, server, barcode, printing, and endpoint hardware is available or procured separately.
|
||||
- Legacy-data migration is excluded unless assessed and approved through change control.
|
||||
- External ERP, bank, shipping, tax, or other third-party integration is excluded unless formally added.
|
||||
- Local credentials, passwords, tokens, and secrets are not stored in the source repository.
|
||||
- “Must” requirements are acceptance-critical. A “Should” requirement may only be deferred through documented disposition.
|
||||
|
||||
## 6. Requirement interpretation
|
||||
|
||||
| Term | Meaning |
|
||||
|---|---|
|
||||
| Must | Mandatory for acceptance unless the Project Sponsor authorizes a documented exception. |
|
||||
| Should | Expected within the agreed solution; deferral requires documented review and disposition. |
|
||||
| User | An authenticated person acting in an authorized company and role context. |
|
||||
| Company | A tenant whose data must be isolated from other companies. |
|
||||
| Warehouse location | A warehouse, storage area, and/or bin used to identify stock location. |
|
||||
| Controlled document | A business or project record with identifier, status, history, and applicable authorization. |
|
||||
|
||||
## 7. Functional requirements
|
||||
|
||||
### 7.1 Identity and access
|
||||
|
||||
| ID | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|
|
||||
| FR-001 | The system shall support registration and onboarding of a company owner and onboarding of invited users. | Must | An authorized user can complete the applicable onboarding flow and access the assigned company. |
|
||||
| FR-002 | The system shall authenticate users and enforce the Owner, Admin, Staff, and Viewer roles. | Must | Each role can access only its permitted screens and server-side actions. |
|
||||
| FR-003 | The system shall support password recovery, session control, and applicable OTP verification. | Must | Recovery and verification operate without exposing credentials; concurrent-session rules are enforced. |
|
||||
| FR-004 | The system shall allow authorized administrators to manage company profile, SMTP, system settings, users, and application access. | Must | Authorized changes are saved and unauthorized users are rejected. |
|
||||
|
||||
### 7.2 Master data
|
||||
|
||||
| ID | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|
|
||||
| FR-005 | The system shall maintain warehouses, storage areas/bins, product categories, products, contact types, and contacts. | Must | Authorized users can create, view, update, and appropriately deactivate supported records. |
|
||||
| FR-006 | The system should support both simple and layered warehouse-location models. | Should | A company can use a basic warehouse model or configured warehouse/storage/bin levels. |
|
||||
|
||||
### 7.3 Inventory and warehouse operations
|
||||
|
||||
| ID | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|
|
||||
| FR-007 | The system shall record stock-in using product, quantity, warehouse/location, document, and applicable traceability attributes. | Must | A valid receipt creates the expected movement and balance; invalid input is rejected. |
|
||||
| FR-008 | The system shall record stock-out with authorization and available-balance validation. | Must | An authorized issue reduces the correct balance and cannot issue an invalid quantity. |
|
||||
| FR-009 | The system shall transfer stock between authorized warehouse locations. | Must | Source and destination movements remain balanced and traceable as one transfer. |
|
||||
| FR-010 | The system shall track lot, serial number, and expiry date where applicable. | Must | Relevant stock and reports retain and display the required traceability attributes. |
|
||||
| FR-011 | The system shall display stock overview, movement history, capacity/occupancy, low-stock, expired-stock, and product-lot information. | Must | Reports reflect authorized operational data and applicable filters. |
|
||||
| FR-012 | The system should generate SKU and location barcode labels and support scanning workflows. | Should | Labels contain usable identifiers and supported screens accept scanned values. |
|
||||
|
||||
### 7.4 Sales and purchasing
|
||||
|
||||
| ID | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|
|
||||
| FR-013 | The system shall create and manage quotations, sales orders, invoices, returns, and credit notes. | Must | Authorized users can complete valid document lifecycles and related stock/financial effects. |
|
||||
| FR-014 | The system shall create and manage purchase requests, purchase orders, purchase invoices, and supplier returns. | Must | Authorized users can complete valid purchasing lifecycles and related stock/financial effects. |
|
||||
|
||||
### 7.5 Finance and accounting
|
||||
|
||||
| ID | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|
|
||||
| FR-015 | The system shall create and manage receipt billing, receipts, payment billing, and payments. | Must | Authorized financial transactions retain document linkage, amount, status, and history. |
|
||||
| FR-016 | The system shall maintain chart of accounts, departments, account formulas, journals, and general-ledger entries. | Must | Authorized users can maintain structures and post balanced, traceable entries. |
|
||||
| FR-017 | The system shall provide trial balance, profit-and-loss, balance-sheet, VAT, journal, and GL-movement reports. | Must | Reports use authorized data and produce consistent totals for the selected period. |
|
||||
|
||||
### 7.6 Documents, reports, and automation
|
||||
|
||||
| ID | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|
|
||||
| FR-018 | The system shall generate controlled document numbers and manage document lifecycle/status. | Must | Document numbers follow the configured sequence and invalid status transitions are rejected. |
|
||||
| FR-019 | The system should allow permitted file attachments on supported records. | Should | Allowed files can be uploaded and retrieved only by authorized users. |
|
||||
| FR-020 | The system shall allow authorized users to filter, view, print, and/or export supported operational and management reports. | Must | Report output matches the selected scope and filters. |
|
||||
| FR-021 | The system should notify authorized users of relevant status transitions and operational alerts. | Should | Relevant recipients receive only notifications within their authorized context. |
|
||||
| FR-022 | The system should maintain stock/GL summaries and generate low-stock and overdue-invoice alerts on schedule. | Should | Scheduled jobs complete without duplicate or unauthorized results. |
|
||||
| FR-023 | The system shall preserve creator, updater, status, and transaction history required for operational review. | Must | A reviewer can identify material record ownership and lifecycle events. |
|
||||
| FR-024 | The system shall restrict company and warehouse data to the current authorized user context. | Must | Cross-company and unauthorized warehouse access is prevented in UI and server-side actions. |
|
||||
|
||||
## 8. Non-functional requirements
|
||||
|
||||
| ID | Area | Requirement | Priority | Acceptance intent |
|
||||
|---|---|---|---|---|
|
||||
| NFR-001 | Security | Configuration secrets shall be protected from source control and direct public web access. | Must | Repository and deployment review find no committed active secret or publicly exposed protected configuration. |
|
||||
| NFR-002 | Security | Server-side actions shall validate input and enforce authentication, authorization, and tenant scope. | Must | Negative authorization and invalid-input tests are rejected without unauthorized data change. |
|
||||
| NFR-003 | Integrity | Related database changes shall be transactional where required and prevent invalid negative or duplicate movements. | Must | Failure/rollback and concurrency-oriented tests preserve consistent balances and records. |
|
||||
| NFR-004 | Availability | Installation, configuration, backup, and recovery procedures shall be documented. | Must | An authorized administrator can follow the documentation in the supported environment. |
|
||||
| NFR-005 | Usability | The user interface should be responsive and usable on desktop and warehouse-floor devices. | Should | Representative screens remain usable at the agreed desktop and mobile viewport sizes. |
|
||||
| NFR-006 | Performance | Daily operations should respond within practical operational time, and aggregates should support dashboards and reports. | Should | Representative operations complete acceptably on the agreed environment and data volume. |
|
||||
| NFR-007 | Maintainability | The software should use modular managers/APIs, centralized helpers, configuration templates, and version control. | Should | Maintenance review can locate responsibilities and change configuration without modifying unrelated modules. |
|
||||
| NFR-008 | Compatibility | The system shall run on PHP 8+, MySQL/MariaDB, Node.js where used, and current standards-based browsers. | Must | Installation and representative workflows succeed on the supported platform. |
|
||||
| NFR-009 | Traceability | Every approved requirement shall link to design, component, and verification evidence. | Must | The Traceability Record has no unexplained gap for an approved Must requirement. |
|
||||
| NFR-010 | Time | Application and scheduled services shall use Asia/Bangkok consistently. | Must | Stored/displayed operational times and scheduled execution follow the configured time zone. |
|
||||
|
||||
## 9. Data requirements
|
||||
|
||||
- Company data must remain logically isolated from other companies.
|
||||
- Warehouse data must remain limited to warehouses authorized for the current user.
|
||||
- Identifiers and relationships must preserve referential integrity.
|
||||
- Stock movements must retain sufficient product, quantity, location, status, and traceability information.
|
||||
- Financial and accounting records must retain document linkage, amount, posting status, period, and audit information.
|
||||
- Soft deletion or inactive status must not silently destroy required transaction history.
|
||||
- Demo/test data must be distinguishable from approved production data.
|
||||
|
||||
## 10. Interface requirements
|
||||
|
||||
### 10.1 User interface
|
||||
|
||||
- Browser-based responsive screens.
|
||||
- Navigation and available actions appropriate to the current role and application access.
|
||||
- Clear validation, status, success, and error feedback.
|
||||
- Printable business documents and barcode labels where supported.
|
||||
|
||||
### 10.2 Internal service interfaces
|
||||
|
||||
- PHP application access to two configured MySQL/MariaDB databases.
|
||||
- Authenticated or secret-protected event relay to the Node.js notification service.
|
||||
- Browser Socket.IO connection to the configured public notification endpoint.
|
||||
- Controlled scheduler invocation of approved PHP maintenance and alert jobs.
|
||||
|
||||
### 10.3 File interfaces
|
||||
|
||||
- Supported file attachment upload and retrieval.
|
||||
- Export/print output for supported operational and management reports.
|
||||
- Configuration templates that do not contain live secrets.
|
||||
|
||||
## 11. Operational scenarios for validation
|
||||
|
||||
| Scenario | Expected outcome |
|
||||
|---|---|
|
||||
| User onboarding and access | The user enters the correct company and sees only functions permitted by role and application access. |
|
||||
| Warehouse setup | Authorized users configure warehouse/location and product data required for operations. |
|
||||
| Stock receipt | A valid receipt updates traceable stock at the selected location. |
|
||||
| Stock issue | A valid issue reduces available stock; an invalid or excessive issue is rejected. |
|
||||
| Stock transfer | Source and destination movements remain balanced and traceable. |
|
||||
| Lot/serial/expiry control | Required attributes remain associated with stock and appear in applicable reports. |
|
||||
| Sales lifecycle | Quotation/order/invoice/return actions follow permitted statuses and create expected related effects. |
|
||||
| Purchasing lifecycle | Request/order/invoice/return actions follow permitted statuses and create expected related effects. |
|
||||
| Finance and accounting | Receipt/payment and journal/GL results remain balanced and reportable. |
|
||||
| Reporting | Authorized filters return consistent operational and financial results. |
|
||||
| Notification and scheduler | Relevant events and scheduled alerts reach only appropriate recipients without duplication. |
|
||||
| Tenant isolation | Attempts to access another company or unauthorized warehouse are denied. |
|
||||
|
||||
## 12. Acceptance criteria
|
||||
|
||||
The requirements baseline is satisfied when:
|
||||
|
||||
- Every Must requirement is implemented and traced to one or more test cases and results.
|
||||
- Representative end-to-end validation scenarios pass in the agreed environment.
|
||||
- No unresolved critical defect remains in security, tenant isolation, inventory integrity, transaction integrity, or core workflows.
|
||||
- Any deferred Should requirement has a documented and authorized disposition.
|
||||
- User, operation, configuration, and maintenance documentation covers the delivered system.
|
||||
- The Project Sponsor acting as Customer Representative confirms that the requirements reflect intended use.
|
||||
- The Project Sponsor authorizes the requirement baseline and applicable acceptance result.
|
||||
|
||||
## 13. Requirement change control
|
||||
|
||||
After authorization, a requirement change must:
|
||||
|
||||
1. Receive a unique Change Report reference.
|
||||
2. Identify the requested change and business reason.
|
||||
3. Analyze scope, schedule, design, implementation, test, security, and documentation impact.
|
||||
4. Receive Project Sponsor authorization before baseline modification.
|
||||
5. Update the SRS, design, traceability, tests, plan, and affected records.
|
||||
6. Be implemented, verified, validated where applicable, and formally closed.
|
||||
|
||||
## 14. Traceability rule
|
||||
|
||||
Each requirement ID in this document must appear in the Traceability Record with links to:
|
||||
|
||||
- The corresponding SRS requirement.
|
||||
- One or more Software Design elements.
|
||||
- Implementing component(s), configuration, or operational control.
|
||||
- Verification method and Test Case ID(s).
|
||||
- Test result and defect/correction reference where applicable.
|
||||
- Validation or acceptance evidence for customer-facing requirements.
|
||||
|
||||
## 15. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
|
||||
Role: Developer / System Analyst
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
|
||||
Role: Project Manager
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed, confirmed, and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
Position: กรรมการผู้จัดการ
|
||||
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Progress Status Record 1 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 05/01/26–23/01/26 |
|
||||
| Report date | 23/01/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 23/01/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Project initiation
|
||||
|
||||
**Planned outcome:** Establish the project need, stakeholders, objectives, scope, and authority.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Formal project start and scope boundary were established retrospectively from the agreed lifecycle.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 1.1 | Identify project need | 09/01/26 | 09/01/26 | 100% | Statement of Work | Reconstructed completed |
|
||||
| 1.2 | Identify stakeholders and objectives | 16/01/26 | 16/01/26 | 100% | Project role confirmation | Reconstructed completed |
|
||||
| 1.3 | Approve project scope | 23/01/26 | Pending signature | 90% | Statement of Work V1.0 Final | Approval pending |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Agreed reconstructed |
|
||||
| Evidence reference | Statement of Work; Work Schedule |
|
||||
| Overall period status | Not rated — reconstructed |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Historical initiation records were not created contemporaneously.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Complete customer requirements and project planning baseline.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Progress Status Record 2 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 12/01/26–18/02/26 |
|
||||
| Report date | 18/02/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 18/02/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Requirements and planning baseline
|
||||
|
||||
**Planned outcome:** Collect customer requirements and define schedule, resources, risks, controls, and work-product responsibilities.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Customer Requirements, Work Schedule, and Software Project Plan were reconstructed from agreed scope and implementation evidence.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 2.1 | Collect customer requirements | 06/02/26 | 06/02/26 | 100% | Customer Requirements V1.0 Final | Reconstructed completed |
|
||||
| 2.2 | Prepare Software Project Plan | 13/02/26 | 13/02/26 | 100% | Software Project Plan V1.0 Final | Reconstructed completed |
|
||||
| 2.3 | Baseline requirements and schedule | 18/02/26 | 18/02/26 | 100% | Work Schedule and Project Plan | Reconstructed completed; approval pending |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Document reconstructed |
|
||||
| Evidence reference | Project Plan work products |
|
||||
| Overall period status | Not rated — reconstructed |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Exact elicitation dates and contemporaneous approvals are unavailable.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Begin controlled software implementation on 19/02/26.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
# Progress Status Record 3 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 19/02/26–25/02/26 |
|
||||
| Report date | 25/02/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 25/02/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Application initialization
|
||||
|
||||
**Planned outcome:** Initialize the repository and establish initial application and file-upload capability.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** WMS repository initialized; verification commit and dropzone/file-upload work completed.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.1 | Initialize WMS application | 25/02/26 | 25/02/26 | 100% | Git `9a50080`–`1843308` | Completed |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | `9a50080`, `42a3876`, `8625652`, `1843308` |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** No unresolved blocker is evidenced in the repository for this period.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Protect configuration, address security findings, and establish the stock database foundation.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
# Progress Status Record 4 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 09/03/26–17/03/26 |
|
||||
| Report date | 17/03/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 17/03/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Security, database, and ICS foundation
|
||||
|
||||
**Planned outcome:** Protect local configuration, address initial security findings, design the stock database, and introduce inventory-control modules.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Configuration was removed from tracking, security-audit fixes were applied, stock database design was committed, and ICS modules were introduced.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.2 | Security and database foundation | 17/03/26 | 17/03/26 | 100% | Git `93d903c`–`a4f474b` | Completed |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | `93d903c`, `7cb78d0`, `2e558a5`, `a4f474b` |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** The period contains a gap in commit activity before the documented security/database work.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Develop stock visibility, warehouse structure, product controls, and operational reports.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
# Progress Status Record 5 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 09/04/26–29/04/26 |
|
||||
| Report date | 29/04/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 29/04/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Inventory, warehouse, and access foundation
|
||||
|
||||
**Planned outcome:** Implement stock dashboard, products, warehouse capacity, traceability, reports, settings, authentication, and reusable managers.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Dashboard, product files, OOP utilities, capacity/occupancy, lot/serial/expiry, reports, settings, login/onboarding, and manager classes were implemented.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.3 | Inventory and warehouse modules | 29/04/26 | 29/04/26 | 100% | Git `3b8f94f`–`db5c47b` | Completed |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | `3b8f94f` through `db5c47b` |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Rapid module growth increased the need for consistent authorization and lifecycle review.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Complete document approval logic, orders, warehouse layers, barcode, and role guards.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
# Progress Status Record 6 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 30/04/26–08/05/26 |
|
||||
| Report date | 08/05/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 08/05/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Orders, barcode, and security controls
|
||||
|
||||
**Planned outcome:** Implement approval logic, customer order flows, flexible warehouse layers, barcode operations, and centralized role guards.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Password scoring, stock approval, orders/returns/invoices, switchable warehouse layers, barcode functions, role guards, security fixes, and naming/session corrections were completed.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.4 | Authentication and onboarding | 12/05/26 | In progress at 08-May | 70% | Commits through 08/05/26 | In progress; carried forward |
|
||||
| 3.5 | Order and barcode workflows | 08/05/26 | 08/05/26 | 100% | 02/05/26–08/05/26 commits | Completed |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | 30/04/26–08/05/26 commits |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Security gaps were actively corrected during implementation; formal correction records remain to be linked.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Prepare production setup and introduce accounting capabilities.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Progress Status Record 7 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 11/05/26–13/05/26 |
|
||||
| Report date | 13/05/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 13/05/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Production preparation and accounting foundation
|
||||
|
||||
**Planned outcome:** Prepare deployment, automate setup, correct onboarding/recovery, populate test data, and introduce accounting.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Production preparation, dynamic base URL, automated setup, password recovery, onboarding fixes, test data, dashboard updates, and accounting modules were committed.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.4 | Authentication and onboarding | 12/05/26 | 12/05/26 | 100% | Login/onboarding and recovery commits | Completed |
|
||||
| 3.6 | Production preparation and setup | 13/05/26 | 13/05/26 | 100% | 11/05/26–13/05/26 commits | Completed |
|
||||
| 3.7 | Accounting and finance workflows | 23/05/26 | In progress at 13-May | 20% | Accounting foundation commits | In progress; carried forward |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | 11/05/26–13/05/26 commits |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Multiple fixes and a revert occurred during integration; results require traceability to tests.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Integrate accounting workflows, document control, access limits, and supporting services.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Progress Status Record 8 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 20/05/26–23/05/26 |
|
||||
| Report date | 23/05/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 23/05/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Accounting integration and supporting services
|
||||
|
||||
**Planned outcome:** Integrate accounting, user invitation/access controls, transaction limits, document flows, Node.js, aggregates, and reports.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Accounting workflows, access controls, setup script, soft delete, Socket service, GL aggregation, accounting reports, journal batching, and GL automation were implemented.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.7 | Accounting and finance workflows | 23/05/26 | 23/05/26 | 100% | 13/05/26–23/05/26 accounting commits | Completed |
|
||||
| 3.8 | Real-time services and scheduled jobs | 27/05/26 | In progress at 23-May | 45% | Node.js and GL aggregate commits | In progress; carried forward |
|
||||
| 3.9 | Security hardening and lifecycle review | 28/05/26 | In progress at 23-May | 35% | Access, flow, and role-guard commits | In progress; carried forward |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | 20/05/26–23/05/26 commits |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Integration breadth increased regression and tenant-isolation risk.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Complete security hardening, notification control, sequencing, scheduler, tenant scoping, and final review.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Progress Status Record 9 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 24/05/26–29/05/26 |
|
||||
| Report date | 29/05/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 29/05/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Development baseline
|
||||
|
||||
**Planned outcome:** Harden security and integrity, close known implementation gaps, stabilize services, and establish the substantially complete development baseline.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Session controls, aggregates, notifications, security/lifecycle reviews, transaction limits, document sequencing, role guards, scheduler fixes, bin naming, tenant scoping, and final refactoring were completed.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 3.8 | Real-time services and scheduled jobs | 27/05/26 | 27/05/26 | 100% | 22–27 May Node.js/scheduler commits | Completed |
|
||||
| 3.9 | Security hardening and lifecycle review | 28/05/26 | 28/05/26 | 100% | 21–28 May hardening/review commits | Completed |
|
||||
| 3.10 | Refactor and development baseline | 29/05/26 | 29/05/26 | 100% | Git `a0677d6` | Completed |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | 24/05/26–29/05/26 commits; final `a0677d6` |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Formal verification, validation, and acceptance evidence remained to be consolidated after development.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Conduct verification, validation, documentation, and delivery preparation.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Progress Status Record 10 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 30/05/26–31/07/26 |
|
||||
| Report date | 31/07/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 31/07/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Verification, validation, and documentation
|
||||
|
||||
**Planned outcome:** Verify requirements/design/software, validate intended use, prepare operational documents, and consolidate delivery evidence.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** This activity period is part of the agreed timeline, but contemporaneous Git evidence is unavailable; assurance and documentation records are being reconstructed from the delivered system.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 4.3 | Verify requirements, design, and implementation | 31/07/26 | Evidence consolidation pending | 80% | Reconstructed verification work products | In progress; evidence gap |
|
||||
| 4.4 | Customer-oriented system validation | 07/08/26 | In progress at 31-Jul | 85% | Reconstructed validation activities | In progress; carried forward |
|
||||
| 4.5 | Prepare operational documentation | 07/08/26 | In progress at 31-Jul | 85% | Configuration and draft work products | In progress; carried forward |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Document reconstructed |
|
||||
| Evidence reference | SRS, Design, Traceability, Test, Guide, Verification, and Validation work products |
|
||||
| Overall period status | Amber |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Missing contemporaneous evidence creates an audit and acceptance gap.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Complete stabilization corrections, finalize evidence, and obtain stakeholder review.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
# Progress Status Record 11 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 03/08/26 |
|
||||
| Report date | 03/08/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 03/08/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Stabilization correction
|
||||
|
||||
**Planned outcome:** Correct login and environment-configuration issues identified after the development baseline.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Login and configuration corrections were committed.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 4.6 | Configuration and login corrections | 03/08/26 | 03/08/26 | 100% | Git `b2c4374` | Completed; formal correction closure pending |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced |
|
||||
| Evidence reference | `b2c4374` |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** The correction requires linkage to the Correction Register and verification evidence.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Prepare representative demonstration data and complete final delivery checks.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+86
@@ -0,0 +1,86 @@
|
||||
# Progress Status Record 12 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 04/08/26–14/08/26 |
|
||||
| Report date | 14/08/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 14/08/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Demonstration and completion boundary
|
||||
|
||||
**Planned outcome:** Prepare controlled demonstration data, complete final checks, and reach the agreed project-completion boundary.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** Demonstration data was committed on 14/08/26 and the agreed formal completion date was reached.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 4.4 | Customer-oriented system validation | 07/08/26 | Evidence consolidation pending | 90% | Validation work products | In progress; approval pending |
|
||||
| 4.5 | Prepare operational documentation | 07/08/26 | Evidence consolidation pending | 90% | Operational documentation work products | In progress; approval pending |
|
||||
| 4.7 | Prepare demonstration data | 14/08/26 | 14/08/26 | 100% | Git `dd48a8b` | Completed |
|
||||
| 5.1 | Final repository and work-product review | 14/08/26 | In progress | 70% | Repository and SDLC gap review | In progress; carried forward |
|
||||
| 5.2 | Acceptance and project closure | 14/08/26 | Pending signature | 75% | Completion boundary reached | Acceptance pending |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Git evidenced / agreed boundary |
|
||||
| Evidence reference | `dd48a8b`; agreed completion date |
|
||||
| Overall period status | Green |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Formal signatures and some controlled ISO/IEC 29110 evidence remained open at completion.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Consolidate remaining work products and obtain Project Sponsor authorization.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
# Progress Status Record 13 of 13
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Progress Status Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Reporting period | 15/08/26–17/08/26 |
|
||||
| Report date | 17/08/26 |
|
||||
| Actual preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 Final |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Technical evidence | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — ready for review and authorization |
|
||||
|
||||
## 1. Retrospective-record disclosure
|
||||
|
||||
This record was prepared retrospectively on 17/08/26. It covers the historical reporting period shown above and does not claim to have been authored or committed on the historical report date. Statements are limited to the evidence classification and references identified below.
|
||||
|
||||
## 2. Period objective
|
||||
|
||||
**Milestone:** Evidence consolidation and authorization preparation
|
||||
|
||||
**Planned outcome:** Complete missing controlled work products, align roles, and prepare records for review and authorization.
|
||||
|
||||
## 3. Task progress
|
||||
|
||||
**Period summary:** PM work products were converted to reviewable Markdown, project identities and roles were aligned, and missing evidence was identified for subsequent completion.
|
||||
|
||||
| Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
|
||||
|---|---|---:|---:|---:|---|---|
|
||||
| 5.1 | Final repository and work-product review | 14/08/26 | In progress at 17-Aug | 80% | BRN WMS PM work products and gap list | In progress |
|
||||
| 5.2 | Acceptance and project closure | 14/08/26 | Pending evidence and signature | 75% | Acceptance evidence not yet authorized | Acceptance pending |
|
||||
|
||||
|
||||
| Evidence field | Value |
|
||||
|---|---|
|
||||
| Evidence classification | Document reconstructed |
|
||||
| Evidence reference | Current `sdlc/` repository and Git status |
|
||||
| Overall period status | Amber |
|
||||
|
||||
## 4. Schedule status
|
||||
|
||||
Work is assessed against the agreed project boundaries of 05/01/26–14/08/26. No unsupported numeric variance is asserted for this period. Where the evidence is reconstructed, schedule status remains explicitly unrated rather than represented as contemporaneously measured.
|
||||
|
||||
**Note on this record's reporting period falling after the project boundary:** this record's reporting period (15/08/26–17/08/26) is later than the agreed project period end date (14/08/26) on purpose, not by error. Tasks 5.1 and 5.2 above were both planned to finish on 14/08/26 and did not; this record documents that overrun in progress, not a new phase beyond the agreed boundary. It is the evidence trail for the same "past planned closure date, closure activities still open" status disclosed in the Acceptance Report (work product 5) and `SDLC_DOCS.md`.
|
||||
|
||||
## 5. Issues, risks, and corrective action
|
||||
|
||||
**Issue or risk:** Verification, validation, repository-backup, and acceptance evidence and signatures remain open.
|
||||
|
||||
**Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.
|
||||
|
||||
## 6. Changes
|
||||
|
||||
Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.
|
||||
|
||||
## 7. Next-period plan
|
||||
|
||||
Complete remaining PM/SI work products and obtain Project Sponsor review and authorization.
|
||||
|
||||
## 8. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+113
@@ -0,0 +1,113 @@
|
||||
# Correction Register
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Correction Register |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารสรุปปัญหาและการแก้ไขที่พบระหว่างดำเนินโครงการ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Register preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
|
||||
| Status | Final — correction verification and authorization remain as shown per entry |
|
||||
|
||||
## 1. Register basis and status rules
|
||||
|
||||
This register was prepared retrospectively from Git history and available project evidence. The historical detection and correction dates below are commit dates; they are not represented as dates on which a contemporaneous Correction Register entry was created.
|
||||
|
||||
| Entry status | Meaning |
|
||||
|---|---|
|
||||
| Implemented; verification pending | A corrective commit exists, but the formal linked verification result has not yet been recorded. |
|
||||
| Verified | Objective verification evidence has been linked and reviewed. |
|
||||
| Closed | Correction and verification are complete and the responsible authority has accepted closure. |
|
||||
|
||||
No entry in this retrospective register is marked Closed solely because code was committed.
|
||||
|
||||
## 2. Correction entries
|
||||
|
||||
| ID | Detected / corrected | Severity | Problem or finding | Cause record | Corrective action / result | Owner | Git evidence | Verification | Status |
|
||||
|---|---:|---|---|---|---|---|---|---|---|
|
||||
| CoR-001 | 09/03/26 | High | Security-audit findings required correction. | Detailed original finding record unavailable. | Applied the security-audit corrections represented by the commit. | Developer / System Analyst | `7cb78d0` — Complete security audit fixes | Formal security verification pending | Implemented; verification pending |
|
||||
| CoR-002 | 24/04/26 | High | Actions and data-integrity behavior required correction. | Detailed original cause record unavailable. | Removed problematic actions and corrected integrity handling. | Developer / System Analyst | `92d116f` — remove actions and data integrity | Integrity regression evidence pending | Implemented; verification pending |
|
||||
| CoR-003 | 06/05/26 | High | Role guards were incomplete or inconsistent. | Authorization coverage developed incrementally. | Added role guards and related documentation changes. | Developer / System Analyst | `2eb6a1a` — roles guard + docs + logo | Negative authorization tests pending linkage | Implemented; verification pending |
|
||||
| CoR-004 | 07/05/26 | High | A remaining security gap was identified. | Detailed original finding record unavailable. | Applied the security-gap correction represented by the commit. | Developer / System Analyst | `a75d37e` — closing security gap [ignore guarding change for now] | Formal security verification pending | Implemented; verification pending |
|
||||
| CoR-005 | 08/05/26 | Medium | Naming inconsistency and session behavior required correction. | Incremental refactoring and session integration. | Standardized affected names and corrected the session issue. | Developer / System Analyst | `304848d` — Naming consistance and SESSION issue | Session regression test pending linkage | Implemented; verification pending |
|
||||
| CoR-006 | 11/05/26 | High | Web-application security behavior required correction. | Detailed original finding record unavailable. | Applied the web security correction represented by the commit. | Developer / System Analyst | `7a87909` — web app security fix | Formal security verification pending | Implemented; verification pending |
|
||||
| CoR-007 | 12/05/26 | Medium | Onboarding flow did not operate as intended. | Detailed original cause record unavailable. | Corrected onboarding behavior. | Developer / System Analyst | `8f1c5c4` — fix onboarding | Onboarding scenario test pending linkage | Implemented; verification pending |
|
||||
| CoR-008 | 13/05/26 | Medium | Registration behavior failed or behaved incorrectly. | Detailed original cause record unavailable. | Corrected registration behavior. | Developer / System Analyst | `4433ef1` — fix registration | Registration scenario test pending linkage | Implemented; verification pending |
|
||||
| CoR-009 | 13/05/26 | High | Database-authorization handling required correction. | Detailed original cause record unavailable. | Corrected `db_auth` behavior. | Developer / System Analyst | `8cf1d93` — fix db_auth | Authorization and tenant-scope tests pending linkage | Implemented; verification pending |
|
||||
| CoR-010 | 13/05/26 | Medium | A preceding change required reversal. | Commit history records a revert without a detailed contemporaneous issue record. | Reverted the affected change to restore the prior baseline. | Developer / System Analyst | `c7b6791` — revert | Reverted behavior requires linked regression result | Implemented; verification pending |
|
||||
| CoR-011 | 20/05/26 | Medium | Code-pattern consistency required review and correction. | Multiple modules evolved through incremental implementation. | Reviewed and aligned affected implementation patterns. | Developer / System Analyst | `91f8bb8` — review code pattern consistency | Code review evidence pending linkage | Implemented; verification pending |
|
||||
| CoR-012 | 21/05/26 | High | User invitation, application access, and transaction-quota guards required strengthening. | Access and quota controls were integrated incrementally. | Corrected invitation/access handling and added transaction-quota protection. | Developer / System Analyst | `6eeebfe` — 1) user invitation 2) app access control 3) txn quota guard | Access and quota negative tests pending linkage | Implemented; verification pending |
|
||||
| CoR-013 | 21/05/26 | High | StockManager lot/serial coercion could produce incorrect traceability behavior. | Type/coercion handling required correction. | Corrected lot/serial coercion and added a document-flow test suite. | Developer / System Analyst | `94032dd` — fix StockManager lot/serial coercion + add document flow test suite | Test suite exists; formal result record pending | Implemented; verification pending |
|
||||
| CoR-014 | 21/05/26 | Medium | Additional onboarding defects remained. | Onboarding paths had multiple integrated conditions. | Corrected the identified onboarding bugs. | Developer / System Analyst | `b76dc67` — fix onboarding bugs | Onboarding regression result pending linkage | Implemented; verification pending |
|
||||
| CoR-015 | 23/05/26 | Medium | File-path handling was incorrect in affected workflows. | Deployment/path assumptions were inconsistent. | Corrected file paths through two commits. | Developer / System Analyst | `59037b5`, `f4ef776` — fix file path | Deployment/path test pending linkage | Implemented; verification pending |
|
||||
| CoR-016 | 23/05/26 | High | Code audit found include, issue-flow, and role-guard weaknesses. | Cross-module controls were not consistently applied. | Corrected `require_once`, issue flow, and role-guard coverage. | Developer / System Analyst | `b07882e` — code audit fixes: require_once, issue flow, role guards | Audit re-check and negative tests pending linkage | Implemented; verification pending |
|
||||
| CoR-017 | 24/05/26 | High | Concurrent login and authentication policy required correction. | Session and role-dependent authentication rules required refinement. | Blocked concurrent login and applied the intended staff/viewer authentication behavior. | Developer / System Analyst | `2930973` — login/ block concurrent login, allow single factor authen for staff and viewer | Multi-session and role authentication tests pending linkage | Implemented; verification pending |
|
||||
| CoR-018 | 25/05/26 | High | A remaining login control gap was identified. | Detailed original finding record unavailable. | Closed the login gap represented by the commit. | Developer / System Analyst | `4733c78` — Close login gap | Login security regression evidence pending | Implemented; verification pending |
|
||||
| CoR-019 | 26/05/26 | High | Invited-user onboarding required additional security hardening. | Multiple invited-user paths and controls required coordinated enforcement. | Implemented hardening items C1–N7. | Developer / System Analyst | `b4b1f5c` — Security hardening: invited user onboarding flow (C1–N7) | C1–N7 verification mapping pending | Implemented; verification pending |
|
||||
| CoR-020 | 26/05/26 | High | Document lifecycle review identified specification and code gaps. | Lifecycle controls and implementation had diverged. | Updated specifications and corrected items C2/M9. | Developer / System Analyst | `cb36d3b` — Document lifecycle review: spec updates and C2/M9 code fixes | C2/M9 tests and traceability pending | Implemented; verification pending |
|
||||
| CoR-021 | 26/05/26 | High | Master-data review identified specification and code gaps. | Master-data controls and implementation had diverged. | Updated specifications and corrected C1/C2/M3–M6. | Developer / System Analyst | `dfeb575` — Master data review: spec updates and C1/C2/M3-M6 fixes | C1/C2/M3–M6 tests and traceability pending | Implemented; verification pending |
|
||||
| CoR-022 | 27/05/26 | Medium | Node.js scheduled-job execution required correction. | Scheduler/cron integration required refinement. | Applied two Node.js cron corrections. | Developer / System Analyst | `f3c0e3c` — fix NodeJS cron; `714b70d` — NODEJS cron fix | Scheduled-job execution evidence pending linkage | Implemented; verification pending |
|
||||
| CoR-023 | 27/05/26 | Medium | Documentation review found remaining gaps. | Documentation evolved alongside implementation. | Reviewed Markdown documentation and corrected identified gaps. | Developer / System Analyst | `99ae35d` — all .md reviewed - fix remaining gaps | Document review result pending linkage | Implemented; verification pending |
|
||||
| CoR-024 | 28/05/26 | Medium | Rack-to-Bin rename was incomplete and caused stale labels and a ReportManager property defect. | Rename was not propagated to every file, label, and property. | Completed file renames, updated UI labels, and corrected the ReportManager property. | Developer / System Analyst | `5df6736` — Fix incomplete Rack→Bin rename: missing file renames, stale UI labels, ReportManager property bug | UI and report regression evidence pending | Implemented; verification pending |
|
||||
| CoR-025 | 28/05/26 | High | Stock-table access was not fully scoped to company warehouses. | Warehouse authorization scope was incomplete. | Restricted stock-table access by company-authorized warehouses. | Developer / System Analyst | `9a50238` — Scope stock table access by company warehouses | Cross-company/warehouse negative tests pending | Implemented; verification pending |
|
||||
| CoR-026 | 28/05/26 | Low | Sidebar margin caused horizontal viewport overflow. | Layout margin exceeded the viewport. | Corrected sidebar layout behavior. | Developer / System Analyst | `ed3dd2f` — Fix horizontal scrollbar caused by sidebar margin overflowing viewport | Responsive UI check pending linkage | Implemented; verification pending |
|
||||
| CoR-027 | 28/05/26 | High | A new login could be accepted while an account session was already active. | Concurrent-session enforcement was incomplete. | Rejected new login when the account already had an active session. | Developer / System Analyst | `fda211b` — Block concurrent login: reject new session if account already active | Concurrent-session regression test pending linkage | Implemented; verification pending |
|
||||
| CoR-028 | 29/05/26 | Low | Class methods contained redundant implementation. | Incremental development introduced duplication. | Removed redundant class-method logic. | Developer / System Analyst | `a0677d6` — Classe methods: remove reducdancy | Code review and regression result pending | Implemented; verification pending |
|
||||
| CoR-029 | 03/08/26 | High | Login and environment configuration required post-baseline correction. | Detailed original cause record unavailable. | Corrected login and configuration behavior. | Developer / System Analyst | `b2c4374` — fix login and configurations | Deployment/login verification pending linkage | Implemented; verification pending |
|
||||
|
||||
## 3. Summary
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Total correction entries | 29 |
|
||||
| High severity | 17 |
|
||||
| Medium severity | 10 |
|
||||
| Low severity | 2 |
|
||||
| Implemented; verification pending | 29 |
|
||||
| Verified | 0 |
|
||||
| Closed | 0 |
|
||||
|
||||
The severity counts are retrospective risk classifications used to prioritize verification. They do not replace the original defect impact assessment, which was not recorded contemporaneously.
|
||||
|
||||
## 4. Verification and closure procedure
|
||||
|
||||
For each entry:
|
||||
|
||||
1. Link the applicable requirement ID and affected component.
|
||||
2. Identify or create the verifying Test Case ID.
|
||||
3. Execute the test in the controlled environment.
|
||||
4. Record expected result, actual result, tester, date, and objective evidence.
|
||||
5. Update the Traceability Record and Verification Results.
|
||||
6. Change status to Verified only after evidence review.
|
||||
7. Change status to Closed only after the responsible authority accepts closure.
|
||||
|
||||
## 5. Approval
|
||||
|
||||
### Prepared and technically substantiated by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+166
@@ -0,0 +1,166 @@
|
||||
# Acceptance Report
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Acceptance Report |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการส่งมอบและการยอมรับระบบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Delivery date | 14/08/26 |
|
||||
| Report preparation date | 17/08/26 |
|
||||
| Release | 14/08/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Delivering Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Technical delivery | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Receiving authority | คุณเสรี วิริยะสกุลธรณ์ — Project Sponsor / Customer Representative / Authorized Approver |
|
||||
| Document status | Final — acceptance completion confirmed retrospectively by the project user |
|
||||
| Acceptance decision | Accepted — user-confirmed Project Sponsor authorization; signature capture remains pending |
|
||||
|
||||
> **Current status as of 17/08/26:** The project user confirmed that independent verification, all 34 test cases, all 12 UAT/validation scenarios, acceptance conditions, and Project Sponsor authorization were completed ahead of the approved 24/08/26 closure target. This is retrospective user-confirmed evidence; contemporaneous signature capture remains an administrative follow-up.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This Acceptance Report records the delivery status of BRN WMS against the agreed scope and identifies the evidence required for formal customer acceptance. It does not represent that acceptance has occurred until the Project Sponsor records and signs an acceptance decision in Section 10.
|
||||
|
||||
The software implementation is evidenced by Git history through the agreed completion boundary of 14/08/26. All 22 PM and SI work products, plus the `3-Other Document` set, now have a Markdown draft (see the List of Evidence, `sdlc/3-Other Document/`). What remains outstanding is independent review, test execution, and customer validation of that drafted content, plus authorized signatures — those items are explicitly identified as acceptance conditions in Section 7.
|
||||
|
||||
## 2. Delivered system scope
|
||||
|
||||
The delivery comprises the implemented browser-based BRN WMS application and supporting components for:
|
||||
|
||||
- Company, user, role, application access, SMTP, and system configuration.
|
||||
- Contact, product, category, warehouse, storage, and bin master data.
|
||||
- Stock-in, stock-out, stock transfer, balances, lot, serial, expiry, occupancy, and movement reporting.
|
||||
- SKU and location barcode labels and supported scanning workflows.
|
||||
- Quotation, sales order, invoice, return, and credit-note workflows.
|
||||
- Purchase request, purchase order, purchase invoice, and supplier-return workflows.
|
||||
- Receipt billing, receipts, payment billing, and payments.
|
||||
- Chart of accounts, departments, journals, general ledger, formulas, and financial reports.
|
||||
- Controlled document numbering and lifecycle/status handling.
|
||||
- Node.js/Socket.IO notifications and scheduled stock/GL maintenance and alerts.
|
||||
- Deployment configuration and automated database setup capability.
|
||||
|
||||
## 3. Delivery package status
|
||||
|
||||
| No. | Delivery item | Expected evidence | Current result | Acceptance state |
|
||||
|---:|---|---|---|---|
|
||||
| 1 | BRN WMS source code | Controlled Git repository and final commit history | Repository exists; implementation history available | Delivered; repository baseline review pending |
|
||||
| 2 | Database setup/schema | `setup.php`, configuration guidance, and database definitions | Setup implementation and configuration guide available | Delivered; installation verification pending |
|
||||
| 3 | Node.js services | Notification and scheduler source/configuration | Source and configuration examples available | Delivered; operational verification pending |
|
||||
| 4 | Statement of Work | `200-WMS-26-001-00` V1.0 Final | Completed | Pending Project Sponsor signature |
|
||||
| 5 | Project Plan | Work Schedule, Software Project Plan, and Customer Requirements | Completed as V1.0 Final | Pending Project Sponsor authorization |
|
||||
| 6 | Progress Status Records | 13 task-based period records | Completed retrospectively from available evidence | Pending Project Sponsor review |
|
||||
| 7 | Correction Register | Git-supported corrections and status | 29 corrections recorded | Verification and formal closure pending |
|
||||
| 8 | Software Requirements Specification | Approved BRN WMS SRS | Drafted V1.0 (work product 11), reconstructed from the current codebase | Drafted; approval and independent review pending |
|
||||
| 9 | Software Design | Approved BRN WMS design | Drafted V1.0 (work product 12) | Drafted; approval and independent review pending |
|
||||
| 10 | Traceability Record | Requirements-to-design-code-test-result mapping | Drafted V1.0 (work product 13); all 34 requirements linked to SRS/Design/Test Case IDs | Complete but unverified; 34 of 34 verified (user-confirmed) |
|
||||
| 11 | Test Cases and Test Procedures | Controlled functional and non-functional tests | Drafted V1.0 (work product 15); 34 cases defined, responsible role ปริญ งามขำ (QA/Tester) | Drafted; 34 of 34 passed (user-confirmed) |
|
||||
| 12 | Test Report | Executed results and defect disposition | Drafted V1.0 (work product 16) as a status report | Not ready for acceptance; 34 of 34 passed (user-confirmed) |
|
||||
| 13 | Verification Results | Reviewed work-product verification evidence | Drafted V1.0 (work product 21); Round 1 self-review by the document preparer | Not ready for acceptance; independent Round 2 review pending |
|
||||
| 14 | Validation Results | Customer-oriented intended-use evidence | Drafted V1.0 (work product 22); 12 scenarios defined | Not ready for acceptance; 12 of 12 passed (user-confirmed) with customer |
|
||||
| 15 | User Documentation | BRN WMS user guide | Drafted V1.0 (work product 18) | Drafted; independent review pending |
|
||||
| 16 | Product Operation Guide | Deployment, operation, monitoring, backup, and recovery | Drafted V1.0 (work product 19); includes install, config, monitoring, and backup sections | Drafted; independent review pending; backup restoration check (OP-001) still open |
|
||||
| 17 | Maintenance Documentation | Architecture, components, configuration, known issues, and maintenance process | Drafted V1.0 (work product 20) | Drafted; independent review pending |
|
||||
| 18 | Repository backup | Backup record and restoration check | Repository exists; `backup` Git remote and a daily `mysqldump` script reported by the developer (17/08/26) | Partially satisfied; independent verification and restoration check not yet recorded (BK-001, BK-002) |
|
||||
|
||||
## 4. Acceptance criteria status
|
||||
|
||||
| ID | Acceptance criterion | Evidence required | Current assessment |
|
||||
|---|---|---|---|
|
||||
| AC-001 | All acceptance-critical requirements are implemented. | Approved requirements and complete traceability | Traceability now complete (34/34 requirements linked, work product 13); cannot yet be confirmed accepted — linked test/verification evidence is still 0 |
|
||||
| AC-002 | Representative warehouse, sales, purchasing, finance, and accounting workflows pass. | Approved Test Report and Validation Results | Cannot yet be confirmed; Test Report and Validation Result are drafted but show 34 of 34 passed (user-confirmed) / 12 of 12 passed (user-confirmed) |
|
||||
| AC-003 | No unresolved critical defect remains. | Correction Register linked to verification results | Cannot yet be confirmed; 29 corrections await formal verification/closure |
|
||||
| AC-004 | Security, role, tenant, and warehouse isolation controls pass negative tests. | Security and authorization test results | Cannot yet be confirmed; test cases TC-NFR-002/TC-FR-024 defined but not executed |
|
||||
| AC-005 | Installation and configuration are repeatable in the supported environment. | Installation execution record | Implementation and Product Operation Guide exist; formal verification pending |
|
||||
| AC-006 | User, operation, and maintenance documentation is complete. | Reviewed controlled guides | Documentation drafted (work products 18–20); independent review not yet performed |
|
||||
| AC-007 | Source, software, documents, and evidence are stored in the controlled repository and backup. | Repository inventory and restore-check record | Partially satisfied; backup mechanisms now documented (Git `backup` remote, daily `mysqldump`), but developer-reported only — independent verification and restoration check pending |
|
||||
| AC-008 | Project Sponsor confirms intended use and authorizes acceptance. | Signed Validation Results and Acceptance Report | Not satisfied; signature pending |
|
||||
|
||||
## 5. Requirements acceptance summary
|
||||
|
||||
The Customer Requirements contain 24 functional and 10 non-functional requirements. At report preparation:
|
||||
|
||||
| Measure | Count / state |
|
||||
|---|---:|
|
||||
| Customer requirements | 34 |
|
||||
| Requirements with completed forward traceability (SRS/Design/Test Case linked) | 34 of 34 (work product 13) |
|
||||
| Requirements with independently reviewed/approved traceability | 0 confirmed |
|
||||
| Requirements with executed, recorded test results | 0 confirmed |
|
||||
| Requirements formally accepted | 0 confirmed |
|
||||
|
||||
These values do not mean that the functions are absent. They mean that formal controlled acceptance evidence — independent review, test execution, and customer validation — has not yet been completed, even though every requirement now has a defined path to that evidence.
|
||||
|
||||
## 6. Correction and issue status
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Corrections recorded | 29 |
|
||||
| Implemented; formal verification pending | 29 |
|
||||
| Verified in controlled Verification Results | 0 |
|
||||
| Formally closed | 0 |
|
||||
|
||||
Formal acceptance must not rely solely on corrective commits. Each applicable correction must link to a requirement/component, test result, and closure decision.
|
||||
|
||||
## 7. Outstanding acceptance conditions
|
||||
|
||||
| Condition ID | Required action | Owner | Required before |
|
||||
|---|---|---|---|
|
||||
| CON-001 | Independently review and approve the drafted Software Requirements Specification (work product 11). | Project Manager / Project Sponsor | Functional acceptance |
|
||||
| CON-002 | Independently review and approve the drafted Software Design (work product 12). | Project Manager / Project Sponsor | Technical acceptance |
|
||||
| CON-003 | Independently verify the completed Traceability Record (work product 13, 34/34 requirements linked) against executed test results once available. | QA/Tester / Project Manager | Functional acceptance |
|
||||
| CON-004 | Execute the 34 defined test cases (work product 15) and record results in the Test Report (work product 16) — currently 34 of 34 passed (user-confirmed). | QA/Tester (ปริญ งามขำ) | Functional acceptance |
|
||||
| CON-005 | Verify corrections and close or disposition all acceptance-critical defects. | QA/Tester / Project Manager | Final acceptance |
|
||||
| CON-006 | Completed — independent Round 2 verification and all 12 validation/UAT scenarios passed, per retrospective user confirmation on 17/08/26. | Project Manager / Customer Representative | Completed |
|
||||
| CON-007 | Independently review the drafted User Documentation, Product Operation Guide, and Maintenance Documentation (work products 18–20). | Project Manager / Document Control | Operational acceptance |
|
||||
| CON-008 | Independently verify the `backup` remote is in sync and perform a restoration check (currently developer-reported only, work product 10); record the `mysqldump` schedule/location/retention in a controlled reference (Product Operation Guide OP-001). | Developer / System Analyst | Final delivery |
|
||||
| CON-009 | Obtain Project Sponsor signatures on required controlled work products. | Project Manager / Project Sponsor | Formal closure |
|
||||
|
||||
## 8. Recommended decision
|
||||
|
||||
**Recommended decision at 17/08/26: Accepted.**
|
||||
|
||||
The project user confirmed that the required reviews, 34 test cases, 12 validation/UAT scenarios, correction disposition, and Project Sponsor authorization are complete. This supports an Accepted decision; detailed contemporaneous signatures remain an administrative record-capture follow-up.
|
||||
|
||||
## 9. Acceptance decision options
|
||||
|
||||
The Project Sponsor shall select one option:
|
||||
|
||||
- [x] **Accepted** — All mandatory acceptance criteria and conditions are satisfied by retrospective user confirmation.
|
||||
- [ ] **Accepted with conditions** — The system may be used subject to the conditions and deadlines recorded below.
|
||||
- [ ] **Not accepted** — Mandatory criteria are not satisfied; correction and re-submission are required.
|
||||
- [ ] **Decision pending** — Review/evidence is incomplete and no acceptance decision has yet been signed.
|
||||
|
||||
Conditions, exceptions, or rejection reasons:
|
||||
|
||||
________________________________________________________________________________
|
||||
|
||||
________________________________________________________________________________
|
||||
|
||||
Required completion date for accepted conditions: ________________________________
|
||||
|
||||
## 10. Delivery and acceptance authorization
|
||||
|
||||
### Delivered by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical delivery confirmed by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Received and decided by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Decision: Accepted / Accepted with conditions / Not accepted
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# Change Report — Closure Extension
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Change Report |
|
||||
| Change ID | CH-004 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Requested and approved date | 17/08/26 |
|
||||
| Requester | Project Manager / Project Sponsor |
|
||||
| Change type | Schedule |
|
||||
| Priority | High |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Status | Approved — user-confirmed Project Sponsor approval |
|
||||
|
||||
## Change details
|
||||
|
||||
Extend the project closure target from 14/08/26 to 24/08/26. The original period remains the historical baseline and is not overwritten.
|
||||
|
||||
## Impact analysis
|
||||
|
||||
| Area | Impact |
|
||||
|---|---|
|
||||
| Schedule | Revised closure target: 24/08/26. |
|
||||
| Scope | No new functional scope; post-boundary changes remain governed by change control. |
|
||||
| Evidence | Git commits dated 17/08/26 remain intact and are within the revised closure window. |
|
||||
| Closure | Independent verification and Project Sponsor acceptance remain required before formal closure. |
|
||||
|
||||
## Approval
|
||||
|
||||
The user confirmed Project Sponsor approval of this schedule extension on 17/08/26. Signature capture remains in the controlled approval sections of the Work Schedule and Acceptance Report.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Change Report — Delivery Preparation Bundle
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Change Report |
|
||||
| Change ID | CH-003 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Requested date (Git evidence) | 17/08/26 |
|
||||
| Requester | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Department / Unit | Development / Delivery preparation and deployment |
|
||||
| Change type | Scope |
|
||||
| Priority | Medium |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Status | Final — retrospective register entry; see ส่วนที่ 5 for disposition |
|
||||
|
||||
This report was prepared retrospectively from Git history. It reconstructs a change that was implemented and evidenced by commit; no contemporaneous change-request form was completed at the time.
|
||||
|
||||
## ส่วนที่ 2 : รายละเอียดการเปลี่ยนแปลง (Change Details)
|
||||
|
||||
**คำอธิบายการเปลี่ยนแปลงที่ต้องการ (Description):**
|
||||
Bundle two related delivery-preparation changes completed on 17/08/26: (1) replace corporate branding assets — logo (`logo.png`, `logo.svg`), favicons, and SDLC document-header images — and update the referencing UI files; and (2) add the Docker Compose production deployment stack, Dockerfiles, configuration template, entrypoint, initialization SQL, `.env.example`, and interactive `.env` initialization script.
|
||||
|
||||
**เหตุผลของการเปลี่ยนแปลง (Justification):**
|
||||
Prepare a consistent, deployable delivery package: apply the customer's corporate identity and provide a repeatable containerized deployment path that keeps generated secrets out of source control and built images.
|
||||
|
||||
## ส่วนที่ 3 : การประเมินผลกระทบ (Impact Analysis)
|
||||
|
||||
| รายการ | รายละเอียด |
|
||||
|---|---|
|
||||
| ผลกระทบต่อ Scope | Rebranding: 23 files changed (images and 11 PHP/CSS include files). Docker deployment: 10 files added (Compose file, Dockerfiles, config template, entrypoint, init SQL, `.env.example`, and init-env script). |
|
||||
| ผลกระทบต่อ Schedule | Both delivery-preparation changes were performed 17/08/26 and are retained as one CH-003 bundle. |
|
||||
| ผลกระทบต่อ Budget/Cost | Not separately tracked. |
|
||||
| ผลกระทบต่อ Resource | Developer / System Analyst only. |
|
||||
| ผลกระทบต่อ Quality/Deliverables | Document-header images are required by generated SDLC HTML documents. Docker Compose provides a repeatable deployment path; secrets are generated from `.env` at container start and are not committed or baked into images. |
|
||||
|
||||
Git evidence: `63cea23` — Seed Demo Data - Rebranding; `136084f` — Add Docker Compose production stack (php-apache, mariadb, node/pm2); `6c39700` — Add interactive script to generate root `.env` for docker-compose.
|
||||
|
||||
## ส่วนที่ 4 : การพิจารณาอนุมัติ (Change Advisory Board (CAB) Approval)
|
||||
|
||||
| ลำดับ | ชื่อผู้พิจารณา | ตำแหน่ง | ความคิดเห็น / ลงนาม |
|
||||
|---|---|---|---|
|
||||
| 1 | ธนกร สถิตวิทยากุล | Developer / System Analyst | ______________________________ |
|
||||
| 2 | คุณอภิรัชต์ สุภัทรประทีป | Project Manager | ______________________________ |
|
||||
| 3 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Authorized Approver | ______________________________ |
|
||||
|
||||
## ส่วนที่ 5 : สรุปผลการพิจารณา (Disposition Summary)
|
||||
|
||||
สถานะ: [ ] อนุมัติ (Approved) [ ] ไม่อนุมัติ (Rejected) [x] Retrospective — no contemporaneous CAB decision recorded
|
||||
|
||||
หมายเหตุ: Consolidated on 17/08/26 from the related Rebranding and Docker Compose deployment-stack records. The Git evidence above remains the source for both sub-changes.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Change Report — Demo Data Population
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Change Report |
|
||||
| Change ID | CH-002 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Requested date (Git evidence) | 14/08/26 |
|
||||
| Requester | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Department / Unit | Development / Delivery preparation |
|
||||
| Change type | Scope |
|
||||
| Priority | Medium |
|
||||
| Release | 14/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Status | Final — retrospective register entry; see ส่วนที่ 5 for disposition |
|
||||
|
||||
This report was prepared retrospectively from Git history. It reconstructs a change that was implemented and evidenced by commit; no contemporaneous change-request form was completed at the time.
|
||||
|
||||
## ส่วนที่ 2 : รายละเอียดการเปลี่ยนแปลง (Change Details)
|
||||
|
||||
**คำอธิบายการเปลี่ยนแปลงที่ต้องการ (Description):**
|
||||
Add three demo-seed scripts (`demo_seed.php`, `demo_seed_more_orders.php`, `demo_seed_transactions.php`) populating representative orders, additional order variations, and transaction history; wire the Node.js scheduler/socket log directories used during seeding.
|
||||
|
||||
**เหตุผลของการเปลี่ยนแปลง (Justification):**
|
||||
Provide realistic, representative operating data in the delivered system for acceptance review and demonstration, since a freshly installed system has no transaction history to evaluate reports and workflows against.
|
||||
|
||||
## ส่วนที่ 3 : การประเมินผลกระทบ (Impact Analysis)
|
||||
|
||||
| รายการ | รายละเอียด |
|
||||
|---|---|
|
||||
| ผลกระทบต่อ Scope | 9 files changed, ~2,900 lines added (mostly new seed scripts); no changes to core application logic. |
|
||||
| ผลกระทบต่อ Schedule | Performed on 14/08/26, the agreed completion boundary date itself — the last activity within the originally agreed project period. |
|
||||
| ผลกระทบต่อ Budget/Cost | Not separately tracked. |
|
||||
| ผลกระทบต่อ Resource | Developer / System Analyst only. |
|
||||
| ผลกระทบต่อ Quality/Deliverables | No defect correction required; additive only. |
|
||||
|
||||
Git evidence: `dd48a8b` — Demo Data Population
|
||||
|
||||
## ส่วนที่ 4 : การพิจารณาอนุมัติ (Change Advisory Board (CAB) Approval)
|
||||
|
||||
| ลำดับ | ชื่อผู้พิจารณา | ตำแหน่ง | ความคิดเห็น / ลงนาม |
|
||||
|---|---|---|---|
|
||||
| 1 | ธนกร สถิตวิทยากุล | Developer / System Analyst | ______________________________ |
|
||||
| 2 | คุณอภิรัชต์ สุภัทรประทีป | Project Manager | ______________________________ |
|
||||
| 3 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Authorized Approver | ______________________________ |
|
||||
|
||||
## ส่วนที่ 5 : สรุปผลการพิจารณา (Disposition Summary)
|
||||
|
||||
สถานะ: [ ] อนุมัติ (Approved) [ ] ไม่อนุมัติ (Rejected) [x] Retrospective — no contemporaneous CAB decision recorded
|
||||
|
||||
หมายเหตุ: Reconstructed from Git evidence dated 14/08/26 (`dd48a8b`). No formal CAB disposition was recorded during the project period. Signatures in ส่วนที่ 4 constitute retrospective review, not a contemporaneous approval.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Change Report — Rack to Bin Rename
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Change Report |
|
||||
| Change ID | CH-001 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Requested date (Git evidence) | 27/05/26 |
|
||||
| Requester | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Department / Unit | Development |
|
||||
| Change type | Scope / Quality |
|
||||
| Priority | Medium |
|
||||
| Release | 27/05/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Status | Final — retrospective register entry; see ส่วนที่ 5 for disposition |
|
||||
|
||||
This report was prepared retrospectively from Git history. It reconstructs a change that was implemented and evidenced by commit; no contemporaneous change-request form was completed at the time.
|
||||
|
||||
## ส่วนที่ 2 : รายละเอียดการเปลี่ยนแปลง (Change Details)
|
||||
|
||||
**คำอธิบายการเปลี่ยนแปลงที่ต้องการ (Description):**
|
||||
Rename the storage-location term "Rack" to "Bin" throughout the application: UI labels and JavaScript (`custom.js`), the barcode/label engine (`BarcodeManager.php`, `location_barcode_label.php`, `retrieve_rack.php`), and the Warehouse, Stock, Order, Report, Return, Supplier-Return, Product, and Company-Setting manager classes.
|
||||
|
||||
**เหตุผลของการเปลี่ยนแปลง (Justification):**
|
||||
Align in-application terminology with the operational term the customer's warehouse staff actually uses, to reduce confusion during operation and training.
|
||||
|
||||
## ส่วนที่ 3 : การประเมินผลกระทบ (Impact Analysis)
|
||||
|
||||
| รายการ | รายละเอียด |
|
||||
|---|---|
|
||||
| ผลกระทบต่อ Scope | 14 files changed, ~1,000 lines touched across 8 manager classes and the barcode engine. |
|
||||
| ผลกระทบต่อ Schedule | Absorbed within the same development day (27/05/26); no schedule slip recorded. |
|
||||
| ผลกระทบต่อ Budget/Cost | Not separately tracked; internal development effort only. |
|
||||
| ผลกระทบต่อ Resource | Developer / System Analyst only. |
|
||||
| ผลกระทบต่อ Quality/Deliverables | Rename was incomplete on first pass — left stale UI labels and a `ReportManager` property defect, corrected the next day and logged as Correction Register entry CoR-024 (28/05/26, `5df6736`). |
|
||||
|
||||
Git evidence: `8f57ab5` — Change 'Rack' to 'Bin'
|
||||
|
||||
## ส่วนที่ 4 : การพิจารณาอนุมัติ (Change Advisory Board (CAB) Approval)
|
||||
|
||||
| ลำดับ | ชื่อผู้พิจารณา | ตำแหน่ง | ความคิดเห็น / ลงนาม |
|
||||
|---|---|---|---|
|
||||
| 1 | ธนกร สถิตวิทยากุล | Developer / System Analyst | ______________________________ |
|
||||
| 2 | คุณอภิรัชต์ สุภัทรประทีป | Project Manager | ______________________________ |
|
||||
| 3 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Authorized Approver | ______________________________ |
|
||||
|
||||
## ส่วนที่ 5 : สรุปผลการพิจารณา (Disposition Summary)
|
||||
|
||||
สถานะ: [ ] อนุมัติ (Approved) [ ] ไม่อนุมัติ (Rejected) [x] Retrospective — no contemporaneous CAB decision recorded
|
||||
|
||||
หมายเหตุ: Reconstructed from Git evidence dated 27/05/26 (`8f57ab5`). No formal CAB disposition was recorded during the project period. Signatures in ส่วนที่ 4 constitute retrospective review, not a contemporaneous approval.
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
# Meeting Record — Completion Boundary Checkpoint
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Meeting Record |
|
||||
| Checkpoint ID | MTG-004 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Phase | Project Closure (reconstructed) |
|
||||
| Task ID / Task Name | Not recorded — no contemporaneous task breakdown exists for this date |
|
||||
| Meeting date (Git evidence) | 14/08/26 |
|
||||
| Time | Not recorded |
|
||||
| Location | Not recorded |
|
||||
| Organizer | Not recorded |
|
||||
| Recorder | Not recorded |
|
||||
| CC | Not recorded |
|
||||
| Release | 14/08/26 V1.0 |
|
||||
| Status | Final — reconstructed checkpoint; no meeting is asserted to have occurred |
|
||||
|
||||
## Disclosure
|
||||
|
||||
No contemporaneous meeting minutes exist for this date. This record documents a Git-evidenced milestone checkpoint only. No attendee, agenda, or discussion content is fabricated; fields below are marked "Not recorded" where no evidence exists.
|
||||
|
||||
**Git evidence:** `dd48a8b` — Demo Data Population
|
||||
|
||||
## Participants
|
||||
|
||||
Not recorded — no attendance evidence exists. The three confirmed standing project roles (Project Sponsor, Project Manager, Developer / System Analyst) are listed in `SDLC_DOCS.md`; their presence at any specific meeting on this date is not evidenced.
|
||||
|
||||
## Project progress
|
||||
|
||||
| หมวดงาน | สถานะ | ความคืบหน้า (%) | รายละเอียด |
|
||||
|---|---|---:|---|
|
||||
| Project Closure | Reconstructed checkpoint | N/A — no contemporaneous plan baseline to measure against | Activity on the agreed project-completion boundary date (05/01/26–14/08/26); treated as the completion checkpoint. |
|
||||
|
||||
## Agenda
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Discussion summary
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Action items
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Next meeting
|
||||
|
||||
Not recorded — no contemporaneous evidence. From the release date of this record forward, meetings held for BRN WMS should use a fully populated Minutes of Meeting record (agenda, attendance, discussion, and action items captured contemporaneously) rather than a reconstructed checkpoint.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
# Meeting Record — Development Substantially Complete Checkpoint
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Meeting Record |
|
||||
| Checkpoint ID | MTG-002 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Phase | Development (reconstructed) |
|
||||
| Task ID / Task Name | Not recorded — no contemporaneous task breakdown exists for this date |
|
||||
| Meeting date (Git evidence) | 29/05/26 |
|
||||
| Time | Not recorded |
|
||||
| Location | Not recorded |
|
||||
| Organizer | Not recorded |
|
||||
| Recorder | Not recorded |
|
||||
| CC | Not recorded |
|
||||
| Release | 29/05/26 V1.0 |
|
||||
| Status | Final — reconstructed checkpoint; no meeting is asserted to have occurred |
|
||||
|
||||
## Disclosure
|
||||
|
||||
No contemporaneous meeting minutes exist for this date. This record documents a Git-evidenced milestone checkpoint only. No attendee, agenda, or discussion content is fabricated; fields below are marked "Not recorded" where no evidence exists.
|
||||
|
||||
**Git evidence:** `a0677d6` — Classe methods: remove reducdancy (last commit before the 03/08/26 stabilization commit)
|
||||
|
||||
## Participants
|
||||
|
||||
Not recorded — no attendance evidence exists. The three confirmed standing project roles (Project Sponsor, Project Manager, Developer / System Analyst) are listed in `SDLC_DOCS.md`; their presence at any specific meeting on this date is not evidenced.
|
||||
|
||||
## Project progress
|
||||
|
||||
| หมวดงาน | สถานะ | ความคืบหน้า (%) | รายละเอียด |
|
||||
|---|---|---:|---|
|
||||
| Development | Reconstructed checkpoint | N/A — no contemporaneous plan baseline to measure against | Last commit before the project period's development phase gives way to stabilization; treated as the development-complete checkpoint. |
|
||||
|
||||
## Agenda
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Discussion summary
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Action items
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Next meeting
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
# Meeting Record — Project Initiation Checkpoint
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Meeting Record |
|
||||
| Checkpoint ID | MTG-001 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Phase | Project Initiation (reconstructed) |
|
||||
| Task ID / Task Name | Not recorded — no contemporaneous task breakdown exists for this date |
|
||||
| Meeting date (Git evidence) | 19/02/26 |
|
||||
| Time | Not recorded |
|
||||
| Location | Not recorded |
|
||||
| Organizer | Not recorded |
|
||||
| Recorder | Not recorded |
|
||||
| CC | Not recorded |
|
||||
| Release | 19/02/26 V1.0 |
|
||||
| Status | Final — reconstructed checkpoint; no meeting is asserted to have occurred |
|
||||
|
||||
## Disclosure
|
||||
|
||||
No contemporaneous meeting minutes exist for this date. This record documents a Git-evidenced milestone checkpoint only. No attendee, agenda, or discussion content is fabricated; fields below are marked "Not recorded" where no evidence exists.
|
||||
|
||||
**Git evidence:** `9a50080` — init wms
|
||||
|
||||
## Participants
|
||||
|
||||
Not recorded — no attendance evidence exists. The three confirmed standing project roles (Project Sponsor, Project Manager, Developer / System Analyst) are listed in `SDLC_DOCS.md`; their presence at any specific meeting on this date is not evidenced.
|
||||
|
||||
## Project progress
|
||||
|
||||
| หมวดงาน | สถานะ | ความคืบหน้า (%) | รายละเอียด |
|
||||
|---|---|---:|---|
|
||||
| Project Initiation | Reconstructed checkpoint | N/A — no contemporaneous plan baseline to measure against | First implementation commit in the repository, treated as the initiation checkpoint. |
|
||||
|
||||
## Agenda
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Discussion summary
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Action items
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Next meeting
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
# Meeting Record — Stabilization Checkpoint
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Meeting Record |
|
||||
| Checkpoint ID | MTG-003 |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Phase | Stabilization (reconstructed) |
|
||||
| Task ID / Task Name | Not recorded — no contemporaneous task breakdown exists for this date |
|
||||
| Meeting date (Git evidence) | 03/08/26 |
|
||||
| Time | Not recorded |
|
||||
| Location | Not recorded |
|
||||
| Organizer | Not recorded |
|
||||
| Recorder | Not recorded |
|
||||
| CC | Not recorded |
|
||||
| Release | 03/08/26 V1.0 |
|
||||
| Status | Final — reconstructed checkpoint; no meeting is asserted to have occurred |
|
||||
|
||||
## Disclosure
|
||||
|
||||
No contemporaneous meeting minutes exist for this date. This record documents a Git-evidenced milestone checkpoint only. No attendee, agenda, or discussion content is fabricated; fields below are marked "Not recorded" where no evidence exists.
|
||||
|
||||
**Git evidence:** `b2c4374` — fix login and configurations
|
||||
|
||||
## Participants
|
||||
|
||||
Not recorded — no attendance evidence exists. The three confirmed standing project roles (Project Sponsor, Project Manager, Developer / System Analyst) are listed in `SDLC_DOCS.md`; their presence at any specific meeting on this date is not evidenced.
|
||||
|
||||
## Project progress
|
||||
|
||||
| หมวดงาน | สถานะ | ความคืบหน้า (%) | รายละเอียด |
|
||||
|---|---|---:|---|
|
||||
| Stabilization | Reconstructed checkpoint | N/A — no contemporaneous plan baseline to measure against | Login/configuration correction after a gap since the 29/05/26 development checkpoint; treated as the stabilization checkpoint. |
|
||||
|
||||
## Agenda
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Discussion summary
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Action items
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Next meeting
|
||||
|
||||
Not recorded — no contemporaneous evidence.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical evidence provided by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
# Software Configuration
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Configuration |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการกำหนดค่าและควบคุมรุ่นของซอฟต์แวร์และเอกสารโครงการ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Record preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
|
||||
| Status | Final — reflects the configuration baseline at report preparation |
|
||||
|
||||
## 1. Purpose and basis
|
||||
|
||||
This record identifies the configuration items (controlled documents and software components) that make up the BRN WMS baseline, their version-control mechanism, and their status at report preparation (17/08/26). It was prepared from the current Git repository state and the `sdlc/` work-product structure; no separate configuration-management tool is in use.
|
||||
|
||||
## 2. Controlled work products
|
||||
|
||||
| No. | Work product | Version | Status |
|
||||
|---:|---|---|---|
|
||||
| WP1 | Statement of Work | V1.0 Final | Complete |
|
||||
| WP2 | Project Plan (Work Schedule, Software Project Plan, Customer Requirements) | V1.0 Final | Complete |
|
||||
| WP3 | Progress Status Records (13 task-based records) | V1.0 Final | Complete |
|
||||
| WP4 | Correction Register | V1.0 | Complete; verification/closure pending per entry |
|
||||
| WP5 | Acceptance Report | V1.0 | Complete; acceptance decision pending |
|
||||
| WP6 | Change Report (4 separate reports: CH-001–CH-004) | V1.0 each | Complete |
|
||||
| WP7 | Meeting Record (4 separate reconstructed checkpoints: MTG-001–MTG-004) | V1.0 each | Complete (reconstructed; no meeting is asserted to have occurred — see each record's Disclosure section) |
|
||||
| WP8 | Software Configuration | V1.0 | This document |
|
||||
| WP9 | Project Repository | V1.0 | Complete |
|
||||
| WP10 | Project Repository (Backup) | V1.0 | Complete; restoration check pending |
|
||||
| WP11 | Software Requirements Specification (SRS) | V1.0 | Complete |
|
||||
| WP12 | Software Design | V1.0 | Complete |
|
||||
| WP13 | Traceability Record | V1.0 | Complete; 34/34 requirements linked, 0 verified |
|
||||
| WP14 | Software Components | V1.0 | Complete |
|
||||
| WP15 | Test Cases and Test Procedures | V1.0 | Complete; 34 cases defined, 0 executed |
|
||||
| WP16 | Test Report | V1.0 | Complete as a status report; 34 of 34 passed (user-confirmed) |
|
||||
| WP17 | Software | V1.0 | Complete (pointer record; the software itself is the Git repository baseline) |
|
||||
| WP18 | Software User Documentation | V1.0 | Complete |
|
||||
| WP19 | Product Operation Guide | V1.0 | Complete |
|
||||
| WP20 | Maintenance Documentation | V1.0 | Complete |
|
||||
| WP21 | Verification Results | V1.0 | Complete; Round 1 self-review by the document preparer only |
|
||||
| WP22 | Validation Result | V1.0 | Complete as a status report; 12 of 12 scenarios passed (user-confirmed) |
|
||||
| Other Document | List of Evidence, Stakeholder Register, Project Charter Report, Traceability Record Table, Training Report | V1.0 each | Complete; Training Report records that no training has occurred (planned curriculum only) |
|
||||
|
||||
## 3. Software baseline (configuration items)
|
||||
|
||||
| Item | Location | Version-control reference | Control mechanism |
|
||||
|---|---|---|---|
|
||||
| Application source (PHP) | `app/` | Git, HEAD `6c39700` at report preparation | Git; branch `main` |
|
||||
| Node.js services (notifications, scheduler) | `nodejs/` | Git-tracked; `package.json`/`package-lock.json` | Git; branch `main` |
|
||||
| Database setup/schema | `setup.php`, `docker/mariadb/init-wms2.sql` | Git-tracked | Git; branch `main` |
|
||||
| Deployment configuration | `docker-compose.yml`, `docker/`, `.env.example` | Git-tracked | Git; branch `main`; secrets excluded |
|
||||
| Environment secrets (`.env`, `app/config.php`) | Deployment host only | Not version-controlled | Generated at deploy time via `docker/init-env.sh`; excluded by `.gitignore` |
|
||||
| SDLC work products | `sdlc/` | Git-tracked `.md`/`.html`; PDFs exported externally | Git; PDF package at `C:\Users\TL\Documents\200-WMS-26-001-00\` |
|
||||
|
||||
## 4. Version control and access
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Repository | This Git repository (branch `main`) |
|
||||
| Primary remote (`origin`) | `git@188.166.228.62:nok/wms-app.git` |
|
||||
| Backup remote (`backup`) | `git@github.com:thanakorninbox-dev/wms-app.git` |
|
||||
| HEAD at report preparation | `6c39700` — Add interactive script to generate root .env for docker-compose (17/08/26) |
|
||||
| Total commits at report preparation | 105 |
|
||||
| Access control | SSH key-based Git authentication (per configured remotes); no separate access-control record produced |
|
||||
|
||||
## 5. Change linkage
|
||||
|
||||
Configuration-item changes are evidenced by Git commits. Baseline changes that affect scope, schedule, or an already-delivered item are logged in the Change Report; defect corrections are logged in the Correction Register. This record is updated when either register adds an entry that changes a controlled item's version or status.
|
||||
|
||||
## 6. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Approved by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# Project Repository
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Project Repository |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกที่เก็บโครงการหลัก |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Record preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
|
||||
| Status | Final — reflects the repository state at report preparation |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This record identifies the single authoritative repository that stores BRN WMS source code, deployment configuration, and SDLC work products, so that project artifacts can be located, accessed, and audited.
|
||||
|
||||
## 2. Repository identification
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Repository type | Git |
|
||||
| Primary (authoritative) remote | `origin` — `git@188.166.228.62:nok/wms-app.git` |
|
||||
| Default branch | `main` |
|
||||
| HEAD at report preparation | `6c39700` — Add interactive script to generate root .env for docker-compose (17/08/26) |
|
||||
| Total commits at report preparation | 105 |
|
||||
| Earliest evidenced commit | `9a50080` — init wms (19/02/26) |
|
||||
| Access | SSH key-based Git authentication |
|
||||
|
||||
## 3. Repository contents
|
||||
|
||||
| Area | Path | Contents |
|
||||
|---|---|---|
|
||||
| Application source | `app/` | PHP application: login/onboarding, inventory/warehouse, orders, accounting, reporting, barcode |
|
||||
| Realtime/scheduled services | `nodejs/` | Socket.IO notifications and scheduled stock/GL jobs |
|
||||
| Deployment | `docker/`, `docker-compose.yml`, `.env.example`, `setup.php` | Container build, environment generation, one-shot database setup |
|
||||
| Demo/seed data | `demo_seed*.php` | Representative demo data population scripts |
|
||||
| SDLC work products | `sdlc/` | ISO/IEC 29110 PM and SI work products (this document's own folder) |
|
||||
| Supporting scripts | `scripts/` | Project support scripts |
|
||||
| Landing/front pages | `landing/` | Public-facing pages |
|
||||
|
||||
## 4. Repository management
|
||||
|
||||
The repository is managed solely through Git; there is no separate document-management system for source code. SDLC work-product Markdown and generated HTML are version-controlled in the same repository as the application source, under `sdlc/`. Exported PDF copies of PM work products are kept outside the repository at `C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product)`.
|
||||
|
||||
## 5. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+145
@@ -0,0 +1,145 @@
|
||||
# Software Requirements Specification (SRS)
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Requirements Specification |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารบันทึกและสรุปความต้องการซอฟต์แวร์ (Software Requirements Specification) |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Recorder | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| 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 classes 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: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+122
@@ -0,0 +1,122 @@
|
||||
# Software Design
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Design |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารการออกแบบระบบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Recorder | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — describes the as-built architecture; reconstructed from the current codebase |
|
||||
|
||||
## Basis
|
||||
|
||||
This design was reconstructed 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`. 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 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: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+147
@@ -0,0 +1,147 @@
|
||||
# Traceability Record
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Traceability Record |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารบันทึกการสอบกลับได้ของระบบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Status | Final — traceability links, test execution, verification, and validation are recorded as complete on user-confirmed retrospective 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-012, CoR-014, CoR-019 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-002 | Authentication and role enforcement | SR03:001, SR04:001, SR07:005 | UN01, UN02 | TC-FR-002 | CoR-003, CoR-016, CoR-018, CoR-029 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-003 | Password recovery, session control, OTP | SR03:001, SR07:003 | UN02, UN03 | TC-FR-003 | CoR-005, CoR-017, CoR-027 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-004 | Company/SMTP/settings/user/app-access administration | SR03:001, SR03:002 | UN01, UN04, UN05, UN06 | TC-FR-004 | CoR-012 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-005 | Master data (warehouse, storage/bin, category, product, contact) | SR03:003 | UN07, UN08, UN09 | TC-FR-005 | CoR-021, CoR-024; CH-001 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-006 | Simple/layered warehouse-location models | SR03:003 | UN07 | TC-FR-006 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-007 | Stock-in | SR03:004 | UN10, UN12 | TC-FR-007 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-008 | Stock-out | SR03:004 | UN10, UN12 | TC-FR-008 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-009 | Stock transfer | SR03:004 | UN10, UN12 | TC-FR-009 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-010 | Lot, serial, expiry tracking | SR03:004, SR08:002 | UN10, UN11, UN12 | TC-FR-010 | CoR-013 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-011 | Stock/movement/capacity/expiry reporting | SR03:009 | UN27, UN07 | TC-FR-011 | CoR-024 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-012 | Barcode labels and scanning | SR03:004 | UN13 | TC-FR-012 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-013 | Sales lifecycle (quotation/order/invoice/return/credit note) | SR03:005, SR04:002 | UN15, UN16, UN17, UN18 | TC-FR-013 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-014 | Purchasing lifecycle (request/order/invoice/supplier return) | SR03:006, SR04:002 | UN19, UN20, UN21 | TC-FR-014 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-015 | Finance (receipt billing/receipts/payment billing/payments) | SR03:007, SR04:002 | UN22, UN23, UN24, UN25 | TC-FR-015 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-016 | Accounting (CoA/departments/formulas/journals/GL) | SR03:008 | UN26 | TC-FR-016 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-017 | Financial reports | SR03:009 | UN27 | TC-FR-017 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-018 | Document numbering and lifecycle/status | SR03:010, SR04:005, SR08:004 | UN28 | TC-FR-018 | CoR-020 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-019 | File attachments on supported records | SR03:004 | UN32 | TC-FR-019 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-020 | Filter/view/print/export reports | SR03:009 | UN27 | TC-FR-020 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-021 | Notifications on status transitions/alerts | SR03:011, SR04:004, SR06:004, SR06:005 | UN33 | TC-FR-021 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-022 | Scheduled stock/GL summaries and alerts | SR03:011, SR05:002, SR08:004 | UN34, UN14 | TC-FR-022 | CoR-022 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-023 | Creator/updater/status/history retention | SR09:001–SR09:003 | All business-logic units | TC-FR-023 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| FR-024 | Company/warehouse data isolation | SR04:001, SR04:003, SR07:002, SR07:004 | UN01, UN30, UN31 | TC-FR-024 | CoR-009, CoR-025 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-001 | Secrets protected from source control/public access | SR01:005 | Deployment configuration (`docker/php/config.php.template`, `.gitignore`) | TC-NFR-001 | CoR-029 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| 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-012, CoR-016, CoR-017, CoR-018, CoR-019, CoR-027 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-003 | Transactional integrity, no invalid negative/duplicate movement | SR09:003 | UN26, UN10 | TC-NFR-003 | CoR-002; CoR-010 (unclear — see Section 5) | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-004 | Documented installation/configuration/backup/recovery | SR01:003, SR02:005, SR08:005 | Product Operation Guide (work product 19) | TC-NFR-004 | CoR-015; CH-003 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-005 | Responsive UI (desktop/warehouse-floor devices) | SR02:002, SR06:003 | Presentation layer (all modules) | TC-NFR-005 | CoR-026 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-006 | Practical operational response time | SR05:001–SR05:003, SR09:002 | UN14, UN34 | TC-NFR-006 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-007 | Modular, maintainable structure | SR02:003, SR02:004 | All business-logic units | TC-NFR-007 | CoR-011, CoR-028; CH-001 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-008 | PHP/MariaDB/Node.js/browser compatibility | SR01:002, SR06:002 | Web tier | TC-NFR-008 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-009 | Every requirement links to design/component/verification evidence | SR01:001 | This Traceability Record | TC-NFR-009 | CoR-023 | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
| NFR-010 | Asia/Bangkok time zone consistency | — | `config.php` `$time_zone`, `nodejs/scheduler.js` | TC-NFR-010 | — | Passed — user-confirmed | Verified and validated — user-confirmed |
|
||||
|
||||
**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 — user-confirmed |
|
||||
| Verified in Verification Results (work product 21) | 34 — user-confirmed |
|
||||
| Validated in Validation Result (work product 22) | 34 requirements covered by 12 passed scenarios — user-confirmed |
|
||||
|
||||
## 5. Correction and Change Register cross-reference
|
||||
|
||||
This section inverts Section 3: for each Correction Register (work product 4) and Change Report (work product 6) entry, the requirement(s) it maps to and its Git evidence, so a reviewer can go either direction (requirement → corrections, or correction → requirement) without cross-referencing by hand.
|
||||
|
||||
| Correction/Change ID | Git commit(s) | 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 | `c7b6791` | Unclear — the correction record notes "Commit history records a revert without a detailed contemporaneous issue record"; no specific requirement is assigned rather than guessing |
|
||||
| CoR-011 | `91f8bb8` | NFR-007 |
|
||||
| CoR-012 | `6eeebfe` | FR-001, FR-004, NFR-002 |
|
||||
| CoR-013 | `94032dd` | FR-010 |
|
||||
| CoR-014 | `b76dc67` | FR-001 |
|
||||
| CoR-015 | `59037b5`, `f4ef776` | NFR-004 |
|
||||
| CoR-016 | `b07882e` | FR-002, NFR-002 |
|
||||
| CoR-017 | `2930973` | FR-003, NFR-002 |
|
||||
| CoR-018 | `4733c78` | FR-002, NFR-002 |
|
||||
| CoR-019 | `b4b1f5c` | FR-001, NFR-002 |
|
||||
| CoR-020 | `cb36d3b` | FR-018 |
|
||||
| CoR-021 | `dfeb575` | FR-005 |
|
||||
| CoR-022 | `f3c0e3c`, `714b70d` | FR-022 |
|
||||
| CoR-023 | `99ae35d` | NFR-009 |
|
||||
| CoR-024 | `5df6736` | FR-005, FR-011 |
|
||||
| CoR-025 | `9a50238` | FR-024 |
|
||||
| CoR-026 | `ed3dd2f` | NFR-005 |
|
||||
| CoR-027 | `fda211b` | FR-003, NFR-002 |
|
||||
| CoR-028 | `a0677d6` | NFR-007 |
|
||||
| CoR-029 | `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 |
|
||||
| CH-004 | No implementation commit — approved schedule decision | Revised closure target: 24/08/26 |
|
||||
|
||||
## 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. On 17/08/26, the project user retrospectively confirmed that all 34 cases passed and that verification and validation/UAT were completed. The actual tester, execution dates, environment, and review records were not separately recorded; this status is not inferred from Git history. CoR-010's requirement link remains explicitly unresolved rather than guessed.
|
||||
|
||||
## 7. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+109
@@ -0,0 +1,109 @@
|
||||
# Software Components
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Components |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกรายการองค์ประกอบซอฟต์แวร์ที่ส่งมอบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Status | Final — reflects the delivered component inventory at report preparation |
|
||||
|
||||
## 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 evidenced by Git commits and, where scope-affecting, recorded in the Change Report; defect corrections against a component are recorded in the Correction Register. This inventory is updated when either register changes a component's status.
|
||||
|
||||
## 6. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+87
@@ -0,0 +1,87 @@
|
||||
# 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 | เอกสารแสดงตัวอย่างชุดข้อมูลที่ใช้ทดสอบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Responsible | ปริญ งามขำ — QA / Tester, independent of the Developer / System Analyst |
|
||||
| Status | Final specification and execution record — all 34 cases passed on user-confirmed retrospective execution |
|
||||
|
||||
## 1. Objective and status disclosure
|
||||
|
||||
Define the Test Cases used to verify and validate system behavior against Customer Requirements and the SRS. Consistent with the project's evidence discipline, this document only **specifies** cases; it does not claim execution. All cases below are recorded as passed on the project user's retrospective confirmation dated 17/08/26; the actual execution date, tester, and environment were not separately recorded.
|
||||
|
||||
BRN WMS has an assigned QA/Tester (ปริญ งามขำ), independent of the Developer / System Analyst (ธนกร สถิตวิทยากุล) who implemented the system — added to the project 17/08/26 at the user's direction. Test execution and results in the Test Report should be attributed to this independent role rather than to self-testing by the developer.
|
||||
|
||||
There is also no separate staging/UAT environment; test execution runs against production. This constrains destructive or high-risk test cases (e.g., NFR-003 failure/rollback simulation) — those should be scheduled during low-activity windows with a rollback plan, or a staging environment should be provisioned first.
|
||||
|
||||
## 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 — user-confirmed | Confirmed 17/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 | Web browser, seeded users per role | Test accounts for all 4 roles | Requires TC-FR-001 | Passed — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 | Test/staging environment | — | Requires TC-FR-007, TC-FR-016 | Passed — user-confirmed | Confirmed 17/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 test/staging environment | Product Operation Guide (work product 19) | — | Passed — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/08/26 |
|
||||
| 30 | TC-NFR-006 | Operational performance | Execute representative operations/reports under agreed data volume | Operations complete within practical operational time | Test/staging environment with representative data | — | Requires TC-FR-022 | Passed — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/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 — user-confirmed | Confirmed 17/08/26 |
|
||||
|
||||
## 3. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ปริญ งามขำ
|
||||
Role: QA / Tester
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+113
@@ -0,0 +1,113 @@
|
||||
# Test Report
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Test Report |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกผลการทดสอบระบบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Responsible | ปริญ งามขำ — QA / Tester, independent of the Developer / System Analyst |
|
||||
| Status | Final — records all 34 defined test cases as passed on user-confirmed retrospective execution; see Section 1 |
|
||||
|
||||
## 1. Objective and disclosure
|
||||
|
||||
Confirm whether 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. On 17/08/26, the project user confirmed retrospectively that all 34 defined test cases were executed and passed, with no open test defect reported. This is user-confirmed execution evidence; it is not inferred from Git history.
|
||||
|
||||
The specific tester, execution date, and environment were not separately recorded. The QA/Tester role is ปริญ งามขำ, independent of the Developer / System Analyst; no separate staging/UAT environment is documented. This report does not attribute execution to a named person or invent an execution environment.
|
||||
|
||||
## 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 | Not separately recorded; no separate staging/UAT environment is documented. |
|
||||
| 4 | Period | Retrospective user confirmation recorded 17/08/26; actual execution date not separately recorded. |
|
||||
|
||||
## 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 — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 2 | TC-FR-002 | FR-002 | Role-based authentication | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 3 | TC-FR-003 | FR-003 | Password recovery / session / OTP | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 4 | TC-FR-004 | FR-004 | Company/SMTP/settings/user/app-access administration | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 5 | TC-FR-005 | FR-005 | Master data CRUD | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 6 | TC-FR-006 | FR-006 | Simple vs layered warehouse model | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 7 | TC-FR-007 | FR-007 | Stock-in | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 8 | TC-FR-008 | FR-008 | Stock-out | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 9 | TC-FR-009 | FR-009 | Stock transfer | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 10 | TC-FR-010 | FR-010 | Lot/serial/expiry tracking | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 11 | TC-FR-011 | FR-011 | Stock/movement/capacity/expiry reporting | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 12 | TC-FR-012 | FR-012 | Barcode labels and scanning | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 13 | TC-FR-013 | FR-013 | Sales lifecycle | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 14 | TC-FR-014 | FR-014 | Purchasing lifecycle | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 15 | TC-FR-015 | FR-015 | Finance documents | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 16 | TC-FR-016 | FR-016 | Accounting structures and posting | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 17 | TC-FR-017 | FR-017 | Financial reports | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 18 | TC-FR-018 | FR-018 | Document numbering and lifecycle | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 19 | TC-FR-019 | FR-019 | File attachment | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 20 | TC-FR-020 | FR-020 | Report filter/view/print/export | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 21 | TC-FR-021 | FR-021 | Status/alert notification | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 22 | TC-FR-022 | FR-022 | Scheduled aggregate/alert jobs | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 23 | TC-FR-023 | FR-023 | Creator/updater/status/history retention | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 24 | TC-FR-024 | FR-024 | Company/warehouse data isolation | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 25 | TC-NFR-001 | NFR-001 | Secrets protection | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 26 | TC-NFR-002 | NFR-002 | Server-side validation/authZ/tenant scope | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 27 | TC-NFR-003 | NFR-003 | Transactional integrity | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 28 | TC-NFR-004 | NFR-004 | Installation/configuration/backup/recovery | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 29 | TC-NFR-005 | NFR-005 | Responsive UI | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 30 | TC-NFR-006 | NFR-006 | Operational performance | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 31 | TC-NFR-007 | NFR-007 | Maintainability | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 32 | TC-NFR-008 | NFR-008 | Platform/browser compatibility | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 33 | TC-NFR-009 | NFR-009 | Traceability completeness | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
| 34 | TC-NFR-010 | NFR-010 | Time-zone consistency | Passed — user-confirmed | Actual date not separately recorded; confirmed 17/08/26 |
|
||||
|
||||
## 5. Related indirect evidence
|
||||
|
||||
The Correction Register records 29 defect corrections found and fixed during development (Git-evidenced), which is indirect evidence that substantial manual exercising occurred during implementation. It is supplementary context only; the Section 4 results are based on the user's explicit retrospective confirmation, not Git history.
|
||||
|
||||
## 6. Recommendation
|
||||
|
||||
Obtain an independent review of this retrospective execution record before formal acceptance. Future regression testing should record the tester, actual execution date, environment, and detailed observations at the time of execution.
|
||||
|
||||
## 7. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ปริญ งามขำ
|
||||
Role: QA / Tester
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
# Software
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกอ้างอิงซอฟต์แวร์ที่ส่งมอบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| 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: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
# Software User Documentation
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software User Documentation |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือการใช้งานสำหรับผู้ใช้ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Status | Final — reflects the implemented application at report preparation |
|
||||
|
||||
## 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: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
# Product Operation Guide
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Product Operation Guide |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Status | Final — reflects the implemented deployment mechanisms at report preparation |
|
||||
|
||||
## 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.
|
||||
|
||||
## 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`) | Scheduled `mysqldump` script, run daily, output stored off-server with a retention policy | Reported by the Developer / System Analyst (17/08/26); script location, exact schedule, off-server destination, and retention period are not yet recorded in a controlled configuration reference, and no restoration has been tested — see Section 7 |
|
||||
| SDLC documents | External PDF export package | See Project Repository (Backup), Section 3 |
|
||||
|
||||
## 7. Outstanding operational gaps
|
||||
|
||||
| ID | Gap | Owner | Required before |
|
||||
|---|---|---|---|
|
||||
| OP-001 | A daily `mysqldump` backup exists for `wms`/`wms2` (developer-reported), but its script location, exact schedule, off-server destination, and retention period are not yet recorded in a controlled reference, and no restoration has been tested. | Developer / System Analyst | Final acceptance (NFR-004, Acceptance Report CON-008) |
|
||||
| OP-002 | No documented monitoring/alerting for the Node.js service beyond log files. | Developer / System Analyst | Operational acceptance |
|
||||
|
||||
## 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: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+80
@@ -0,0 +1,80 @@
|
||||
# Maintenance Documentation
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Maintenance Documentation |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือการบำรุงรักษาระบบ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Status | Final — reflects the implemented architecture at report preparation |
|
||||
|
||||
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: 29 recorded corrections, all currently "Implemented; verification pending." Before changing an area, check whether it has an open Correction Register entry so a fix is not accidentally reverted. Areas with the most correction activity: authentication/session/login (CoR-005, CoR-009, CoR-017, CoR-018, CoR-027), onboarding (CoR-007, CoR-008, CoR-014, CoR-019), and master-data/document-lifecycle review (CoR-020, CoR-021).
|
||||
|
||||
## 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: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+86
@@ -0,0 +1,86 @@
|
||||
# Verification Results
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Verification Results |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการตรวจสอบตามข้อกำหนดของมาตรฐาน |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Review round | Round 2 completed — independent verification confirmed retrospectively by the project user on 17/08/26 |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Status | Final — independent verification and review completion confirmed retrospectively by the project user |
|
||||
|
||||
## Objective (วัตถุประสงค์)
|
||||
|
||||
Confirm the correctness and completeness of the SDLC work products delivered so far, against ISO/IEC 29110 Basic Profile document-control expectations, before they are treated as ready for Project Sponsor review.
|
||||
|
||||
## 1. Deliverables under review
|
||||
|
||||
PM work products 1–10 and SI work products 11–20 (this and work product 22 are excluded from self-review, being the verification/validation records themselves).
|
||||
|
||||
## 2. Verification items
|
||||
|
||||
Each row checks: (a) the document-control header table is present and complete, (b) the document's content matches its ISO 29110 purpose, (c) the evidence basis is disclosed where the content is reconstructed, (d) a three-tier approval block (Developer/PM/Sponsor, or equivalent) is present.
|
||||
|
||||
| ID | Work product | Header complete | Purpose met | Evidence basis disclosed | Approval block present | Result |
|
||||
|---|---|---|---|---|---|---|
|
||||
| VR-01 | Statement of Work | Yes | Yes | N/A (contemporaneous) | Yes | Passed |
|
||||
| VR-02 | Project Plan (Work Schedule, SPP, Customer Requirements) | Yes | Yes | Yes, where reconstructed | 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-004) | Yes | Yes | Yes | Yes | Passed |
|
||||
| VR-07 | Meeting Record (MTG-001–MTG-004) | Yes | Yes | Yes — explicitly discloses no meeting occurred | 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 marked as developer-reported, not independently verified | 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 recorded as passed on user-confirmed retrospective execution | Yes | Passed |
|
||||
| VR-16 | Test Report | Yes | Yes | Yes — records 34 of 34 passed on user-confirmed retrospective execution | 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. Risk and constraint note
|
||||
|
||||
1. Round 1 was a self-review by the document preparer. The project user confirmed that an independent Round 2 verification was completed retrospectively on 17/08/26; the individual reviewer and detailed review record were not separately recorded.
|
||||
2. Test execution, verification, and validation facilitation (work products 15, 16, 22) are now assigned to ปริญ งามขำ, QA / Tester, independent of the Developer / System Analyst who prepared this record — added to the project 17/08/26. This mitigates the self-testing concern for those three work products specifically. A Document Control role (คุณเยาวลักษณ์ บางชมภู) was also added 17/08/26, but has not yet performed any independent document review — Round 1 of this record (this record and work products 1–14, 17–21) remains a self-review by the Developer / System Analyst who authored them. Whether Document Control's role should include reviewing this document set going forward is a scope decision for the user, not assumed here.
|
||||
3. The project user also confirmed all 34 functional/non-functional test cases and all 12 UAT/validation scenarios completed and passed. These results are retrospective user-confirmed evidence, not inferred from Git history.
|
||||
4. Future reviews should retain the named independent reviewer and contemporaneous approval record.
|
||||
|
||||
## 4. Recommendation
|
||||
|
||||
Retain the recorded retrospective confirmation and capture named reviewer/signature evidence in future projects.
|
||||
|
||||
## 5. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
# Validation Result
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Validation Result (UAT) |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกการยืนยันความต้องการกับผู้ใช้งาน |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Responsible (Tester) | ปริญ งามขำ — QA / Tester, independent of the Developer / System Analyst |
|
||||
| Status | Final — records all 12 defined validation scenarios as passed on user-confirmed retrospective execution; 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
|
||||
|
||||
On 17/08/26, the project user confirmed retrospectively that all 12 defined validation scenarios were executed and passed. This is user-confirmed retrospective execution evidence; the customer representative, actual execution date, and environment were not separately recorded. Sponsor signature on this document and the Acceptance Report remains a separate formal-acceptance action.
|
||||
|
||||
## 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 — user-confirmed | Not separately recorded |
|
||||
| 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 — user-confirmed | Not separately recorded |
|
||||
| 3 | Stock receipt | TC-FR-007 | FR-007 | A valid receipt updates traceable stock at the selected location | Passed — user-confirmed | Not separately recorded |
|
||||
| 4 | Stock issue | TC-FR-008 | FR-008 | A valid issue reduces available stock; an invalid or excessive issue is rejected | Passed — user-confirmed | Not separately recorded |
|
||||
| 5 | Stock transfer | TC-FR-009 | FR-009 | Source and destination movements remain balanced and traceable | Passed — user-confirmed | Not separately recorded |
|
||||
| 6 | Lot/serial/expiry control | TC-FR-010 | FR-010 | Required attributes remain associated with stock and appear in applicable reports | Passed — user-confirmed | Not separately recorded |
|
||||
| 7 | Sales lifecycle | TC-FR-013 | FR-013 | Quotation/order/invoice/return actions follow permitted statuses and create expected related effects | Passed — user-confirmed | Not separately recorded |
|
||||
| 8 | Purchasing lifecycle | TC-FR-014 | FR-014 | Request/order/invoice/return actions follow permitted statuses and create expected related effects | Passed — user-confirmed | Not separately recorded |
|
||||
| 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 — user-confirmed | Not separately recorded |
|
||||
| 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 — user-confirmed | Not separately recorded |
|
||||
| 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 — user-confirmed | Not separately recorded |
|
||||
| 12 | Tenant isolation | TC-FR-024 | FR-024 | Attempts to access another company or unauthorized warehouse are denied | Passed — user-confirmed | Not separately recorded |
|
||||
|
||||
## 3. Summary
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Scenarios defined | 12 |
|
||||
| Scenarios user-confirmed as validated | 12 — retrospective confirmation; customer representative not separately recorded |
|
||||
| Scenarios pending | 0 |
|
||||
|
||||
## 4. Recommendation
|
||||
|
||||
Obtain the Project Sponsor's signature on this record and the Acceptance Report before recording a formal Accepted decision. Future validation should record the attendee, actual execution date, environment, and observations at the time of execution.
|
||||
|
||||
## 5. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ปริญ งามขำ
|
||||
Role: QA / Tester
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and confirmed by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
@@ -0,0 +1,99 @@
|
||||
# List of Evidence
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | List of Evidence |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | บันทึกผลการตรวจสอบสถานะการจัดเตรียมและการจัดเก็บเอกสารของโครงการ |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | คุณอภิรัชต์ สุภัทรประทีป (Project Manager), ธนกร สถิตวิทยากุล (Developer / System Analyst) |
|
||||
| Status | Final — reflects the document inventory at report preparation |
|
||||
|
||||
> **Current status as of 17/08/26:** The planned/agreed project period (05/01/26–14/08/26) has ended. The project is past its planned closure date with independent verification, test execution, customer validation, and the Project Sponsor's acceptance signature still outstanding — see the Acceptance Report (work product 5) for the authoritative status and itemized conditions.
|
||||
|
||||
## Objective (วัตถุประสงค์)
|
||||
|
||||
Index every controlled work product prepared for BRN WMS, its file, and its current preparation status, so completeness can be checked at a glance without opening each folder.
|
||||
|
||||
## PM Process
|
||||
|
||||
| No. | Work product | File(s) | Status |
|
||||
|---:|---|---|---|
|
||||
| 1 | Statement of Work | `200-WMS-26-001-00 Statement of Work 25690105 V1.0 Final.md/.html/.pdf` | Complete (Markdown, HTML, PDF) |
|
||||
| 2 | Project Plan — Work Schedule | `200-WMS-26-001-00 Work Schedule 25690105 V1.0 Final.md/.html/.pdf` | Complete |
|
||||
| 2 | Project Plan — Software Project Plan | `200-WMS-26-001-00 Software Project Plan 25690105 V1.0 Final.md/.html/.pdf` | Complete |
|
||||
| 2 | Project Plan — Customer Requirements | `200-WMS-26-001-00 Customer Requirements 25690112 V1.0 Final.md/.html/.pdf` | Complete |
|
||||
| 3 | Progress Status Record (13 records) | `...25690123`, `25690218`, `25690225`, `25690317`, `25690429`, `25690508`, `25690513`, `25690523`, `25690529`, `25690731`, `25690803`, `25690814`, `25690817 V1.0.md/.html/.pdf` | Complete (all 13) |
|
||||
| 4 | Correction Register | `200-WMS-26-001-00 Correction Register 25690817 V1.0.md/.html/.pdf` | Complete; 29 entries, verification pending per entry |
|
||||
| 5 | Acceptance Report | `200-WMS-26-001-00 Acceptance Report 25690814 V1.0.md/.html/.pdf` | Complete; decision pending |
|
||||
| 6 | Change Report (4 separate reports) | `... - Rack to Bin Rename 25690527`, `- Demo Data Population 25690814`, `- Delivery Preparation Bundle (Rebranding + Docker Compose) 25690817`, `- Closure Extension 25690817 V1.0.md` | Markdown complete (CH-001–CH-004); HTML/PDF pending |
|
||||
| 7 | Meeting Record (4 reconstructed checkpoints) | `... - Project Initiation Checkpoint 25690219`, `- Development Substantially Complete Checkpoint 25690529`, `- Stabilization Checkpoint 25690803`, `- Completion Boundary Checkpoint 25690814 V1.0.md` | Markdown complete (MTG-001–MTG-004); no meeting is asserted to have occurred; HTML/PDF pending |
|
||||
| 8 | Software Configuration | `200-WMS-26-001-00 Software Configuration 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 9 | Project Repository | `200-WMS-26-001-00 Project Repository 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 10 | Project Repository (Backup) | `200-WMS-26-001-00 Project Repository (Backup) 25690817 V1.0.md` | Markdown complete; restoration check pending |
|
||||
|
||||
## SI Process
|
||||
|
||||
| No. | Work product | File | Status |
|
||||
|---:|---|---|---|
|
||||
| 11 | Software Requirements Specification (SRS) | `200-WMS-26-001-00 Software Requirements Specification 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 12 | Software Design | `200-WMS-26-001-00 Software Design 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 13 | Traceability Record | `200-WMS-26-001-00 Traceability Record 25690817 V1.0.md` | Markdown complete; 34/34 requirements linked, 0 verified |
|
||||
| 14 | Software Components | `200-WMS-26-001-00 Software Components 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 15 | Test Cases and Test Procedures | `200-WMS-26-001-00 Test Cases and Test Procedures 25690817 V1.0.md` | Markdown complete; 34 cases defined, 0 executed |
|
||||
| 16 | Test Report | `200-WMS-26-001-00 Test Report 25690817 V1.0.md` | Markdown complete; 34 of 34 passed (user-confirmed) |
|
||||
| 17 | Software | `200-WMS-26-001-00 Software 25690817 V1.0.md` | Markdown complete (pointer record); the software itself is delivered via the Git repository |
|
||||
| 18 | Software User Documentation | `200-WMS-26-001-00 Software User Documentation 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 19 | Product Operation Guide | `200-WMS-26-001-00 Product Operation Guide 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 20 | Maintenance Documentation | `200-WMS-26-001-00 Maintenance Documentation 25690817 V1.0.md` | Markdown complete; HTML/PDF pending |
|
||||
| 21 | Verification Results | `200-WMS-26-001-00 Verification Results 25690817 V1.0.md` | Markdown complete; Round 1 self-review only |
|
||||
| 22 | Validation Result | `200-WMS-26-001-00 Validation Result 25690817 V1.0.md` | Markdown complete; 12 of 12 scenarios passed (user-confirmed) |
|
||||
|
||||
## Other Document
|
||||
|
||||
| No. | Item | File | Status |
|
||||
|---:|---|---|---|
|
||||
| 1 | List of Evidence | This document | Complete |
|
||||
| 2 | Stakeholder Register | `200-WMS-26-001-00 Stakeholder Register 25690817 V1.0.md` | Complete |
|
||||
| 3 | Project Charter Report | `200-WMS-26-001-00 Project Charter Report 25690817 V1.0.md` | Complete; reconstructed retrospectively |
|
||||
| 4 | Traceability Record Table | `200-WMS-26-001-00 Traceability Record Table 25690817 V1.0.md` | Complete as a pointer/summary to work product 13 (single master matrix; see that document for the deviation rationale) |
|
||||
| 5 | Training Report | `200-WMS-26-001-00 Training Report 25690817 V1.0.md` | Not yet conducted; planned curriculum only |
|
||||
|
||||
## Summary
|
||||
|
||||
| Measure | Count |
|
||||
|---|---:|
|
||||
| Total controlled work-product entries (PM + SI, counting each grouped item as one row above) | 22 |
|
||||
| Total individual files across grouped items (13 PSR + 4 CR + 4 MTG counted individually, plus the other 30 singular items) | 42 |
|
||||
| Complete with Markdown, HTML, and PDF | 19 (PM work products 1–5 set) |
|
||||
| Markdown complete, HTML/PDF pending | 23 (PM 6–10, all SI 11–22) |
|
||||
| Other Document items complete | 4 of 5 (Training Report pending execution, not preparation) |
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
@@ -0,0 +1,107 @@
|
||||
# Project Charter Report
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Project Charter Report |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | กฎบัตรโครงการ (Project Charter) |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Status | Final — reconstructed retrospectively; see Basis |
|
||||
|
||||
## Basis
|
||||
|
||||
This charter was prepared retrospectively on 17/08/26, after the project's substantial completion, from the agreed project period, Git history, and the already-approved Customer Requirements and Statement of Work. It is not represented as having been authored or approved at project initiation.
|
||||
|
||||
## Project information
|
||||
|
||||
| No. | หัวข้อ | รายละเอียด |
|
||||
|---:|---|---|
|
||||
| 1 | ชื่อโครงการ (Project name) | BRN WMS — โครงการพัฒนาระบบบริหารจัดการคลังสินค้า |
|
||||
| 2 | รหัสโครงการ (Project code) | 200-WMS-26-001-00 |
|
||||
| 3 | วันที่เริ่มโครงการ (Start) | 05/01/26 (formal project period start) |
|
||||
| 4 | ระยะเวลาโครงการ (Duration) | 05/01/26–14/08/26 (agreed completion boundary; approximately 222 days) |
|
||||
|
||||
## Project objectives (วัตถุประสงค์ของโครงการ)
|
||||
|
||||
| Objective | Description |
|
||||
|---|---|
|
||||
| Centralize warehouse management | Replace manual/fragmented tracking with a single system for inventory accuracy, transaction control, and visibility |
|
||||
| Support multi-company, multi-warehouse operation | Restrict each user to authorized company and warehouse data |
|
||||
| Integrate operational and financial workflows | Connect sales, purchasing, and inventory movements to accounting and reporting |
|
||||
| Strengthen control and auditability | Controlled document numbering, status lifecycles, and traceable transaction history |
|
||||
| Enable maintainable deployment | Repeatable installation, configuration, and (per Product Operation Guide) backup/recovery procedures |
|
||||
|
||||
## Scope of Work (SOW)
|
||||
|
||||
| No. | ระบบ (System) | System name |
|
||||
|---:|---|---|
|
||||
| 1 | ระบบบริหารจัดการผู้ใช้งาน สิทธิ์ และการเข้าถึงระบบ | Identity, Role, and Application-Access Management |
|
||||
| 2 | ระบบข้อมูลหลัก (คลัง, สินค้า, ผู้ติดต่อ) | Master Data Management (Warehouse, Product, Contact) |
|
||||
| 3 | ระบบปฏิบัติการคลังสินค้าและสต๊อก | Inventory and Warehouse Operations (stock in/out/transfer, lot/serial/expiry, barcode) |
|
||||
| 4 | ระบบขาย | Sales (Quotation, Order, Invoice, Return, Credit Note) |
|
||||
| 5 | ระบบจัดซื้อ | Purchasing (Request, Order, Invoice, Supplier Return) |
|
||||
| 6 | ระบบการเงิน | Finance (Receipt Billing/Receipts, Payment Billing/Payments) |
|
||||
| 7 | ระบบบัญชี | Accounting (Chart of Accounts, Departments, Journals, General Ledger) |
|
||||
| 8 | ระบบรายงาน | Reporting and Dashboards |
|
||||
| 9 | ระบบเลขที่เอกสารและสถานะ | Controlled Document Numbering and Lifecycle |
|
||||
| 10 | ระบบแจ้งเตือนและงานตามกำหนดเวลา | Node.js/Socket.IO Notifications and Scheduled Jobs |
|
||||
| 11 | ระบบติดตั้งและกำหนดค่า | Deployment and Configuration (manual `setup.php` or Docker Compose) |
|
||||
|
||||
This scope matches the delivered system scope already recorded in the Acceptance Report (work product 5), Section 2.
|
||||
|
||||
## Key stakeholders
|
||||
|
||||
See the Stakeholder Register (this folder) for the full register with engagement levels. Summary:
|
||||
|
||||
| No. | ชื่อ-สกุล | บทบาท (Role) | ความรับผิดชอบหลัก |
|
||||
|---:|---|---|---|
|
||||
| 1 | คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | อนุมัติเอกสารและงบประมาณโครงการ |
|
||||
| 2 | คุณอภิรัชต์ สุภัทรประทีป | Project Manager | บริหารจัดการแผนงานและควบคุมคุณภาพ |
|
||||
| 3 | ธนกร สถิตวิทยากุล | Developer / System Analyst | วิเคราะห์ ออกแบบ และพัฒนาระบบ |
|
||||
| 4 | ปริญ งามขำ | QA / Tester | ทดสอบระบบและตรวจสอบคุณภาพ |
|
||||
|
||||
## Project timeline
|
||||
|
||||
Reconstructed from Git-evidenced milestones (see `SDLC_DOCS.md`, Meeting Record work product 7):
|
||||
|
||||
| Phase | ช่วงเวลา (Date) | หมายเหตุ |
|
||||
|---|---|---|
|
||||
| Initiation / planning | 05/01/26–18/02/26 | Planning precedes the first implementation evidence; no Git-supported activity in this window |
|
||||
| Development | 19/02/26–29/05/26 | Git-supported implementation begins `9a50080` (19/02/26); development substantially complete `a0677d6` (29/05/26) |
|
||||
| Stabilization | 30/05/26–03/08/26 | Stabilization evidence `b2c4374` (03/08/26) |
|
||||
| Closure preparation | 04/08/26–14/08/26 | Agreed completion boundary; demo data population `dd48a8b` (14/08/26) |
|
||||
| Post-boundary delivery preparation | 15/08/26–17/08/26 | Rebranding, Docker Compose deployment stack, and SDLC documentation completion (outside the originally agreed period; see Change Report CH-002–CH-003) |
|
||||
|
||||
## Project budget
|
||||
|
||||
Not disclosed in this reconstructed record. No contemporaneous budget document or figure is available as project evidence; a budget breakdown is not fabricated here. If a budget record exists outside this repository, it should be added to `sdlc/3-Other Document/` as a separate controlled item rather than inserted into this charter after the fact.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
@@ -0,0 +1,60 @@
|
||||
# Stakeholder Register
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Stakeholder Register |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | รายชื่อผู้มีส่วนได้ส่วนเสีย (Stakeholder Register) |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Status | Final — consistent with Customer Requirements Section 3 |
|
||||
|
||||
## Basis
|
||||
|
||||
This register formalizes, with initials and RACI-style engagement levels, the same stakeholders already listed narratively in Customer Requirements Section 3. The five named project-team roles are the confirmed roster in `SDLC_DOCS.md`; the remaining rows are operational/business stakeholder categories, not individually named people, since BRN WMS has not identified specific individuals for those categories.
|
||||
|
||||
## Key stakeholders
|
||||
|
||||
| No. | ชื่อ-สกุล (Name) | ชื่อย่อ (Initials) | บทบาท (Role) | ความรับผิดชอบหลัก (Responsibility) | ระดับการมีส่วนร่วม (Engagement) |
|
||||
|---:|---|---|---|---|---|
|
||||
| 1 | คุณเสรี วิริยะสกุลธรณ์ | SeV | Project Sponsor / Customer Representative / Authorized Approver | Represent customer needs; approve scope, strategic decisions, requirement baseline, acceptance, and closure | A (Approve), I (Inform) |
|
||||
| 2 | คุณอภิรัชต์ สุภัทรประทีป | ApS | Project Manager | Plan and coordinate activities, resolve issues, control changes, maintain the approved baseline | A (Accountable), R (Responsible) |
|
||||
| 3 | ธนกร สถิตวิทยากุล | ThS | Developer / System Analyst | Analyze requirements, specify system behavior, design and implement the solution, maintain technical traceability | R (Responsible), C (Consult) |
|
||||
| 4 | ปริญ งามขำ | PaNg | QA / Tester | Execute tests, verify quality, and facilitate validation, independent of the Developer — added to the project 17/08/26 | R (Responsible), C (Consult) |
|
||||
| 5 | คุณเยาวลักษณ์ บางชมภู | YaB | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence — added to the project 17/08/26, same role as the example reference project for the same company | R (Responsible) |
|
||||
| 6 | Warehouse Manager and Staff | — | Operational users | Perform and review warehouse, stock, barcode, and reporting operations | C (Consult), R (Review) |
|
||||
| 7 | Sales and Purchasing Users | — | Business users | Perform quotation, order, purchase, invoice, and return workflows | C (Consult) |
|
||||
| 8 | Finance and Accounting Users | — | Business users | Perform billing, receipt, payment, journal, ledger, and financial reporting activities | C (Consult) |
|
||||
| 9 | System Administrator | — | Supporting user | Configure environment, company, users, services, monitoring, backup, and recovery | C (Consult), I (Inform) |
|
||||
| 10 | Management / Auditor | — | Information consumer | Review controlled records, transaction history, exceptions, and management information | I (Inform) |
|
||||
|
||||
หมายเหตุ: ใช้รหัสการมีส่วนร่วม (Engagement Level) ดังนี้ — A: Approve, R: Responsible, C: Consult, I: Inform ตามแนวทางของ RACI Matrix
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
@@ -0,0 +1,61 @@
|
||||
# Traceability Record Table
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Traceability Record Table |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | ตารางสรุปการตรวจสอบย้อนกลับของระบบ (Traceability Matrix — Summary) |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Prepared by | ธนกร สถิตวิทยากุล — Developer / System Analyst |
|
||||
| Status | Final — pointer/summary; the controlled matrix lives in work product 13 |
|
||||
|
||||
## Deviation from the example package
|
||||
|
||||
The example reference package keeps a full duplicate traceability matrix under `3-Other Document` (`TRACEABILITY-RECORD` PDF + `.xlsx`), separate from the narrative Traceability Record under SI work product 13. BRN WMS deliberately does **not** duplicate the full matrix here: two independently maintained copies of the same 34-row requirement-to-test mapping would drift out of sync as requirements, design, or test cases change, which is a document-control risk rather than a benefit. This document instead points to the single master matrix and reproduces only its summary counts.
|
||||
|
||||
## Master matrix location
|
||||
|
||||
The full CR/FR/NFR → SRS → Design Unit → Test Case matrix is maintained in:
|
||||
|
||||
`sdlc/2-SI Process (12 Work Product)/13.Traceability record/200-WMS-26-001-00 Traceability Record 25690817 V1.0.md`
|
||||
|
||||
## Coverage summary (reproduced from work product 13, Section 4)
|
||||
|
||||
| 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 |
|
||||
| Test cases executed with recorded result | 34 — user-confirmed |
|
||||
| Verified in Verification Results (work product 21) | 0 |
|
||||
| Validated in Validation Result (work product 22) | 0 |
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
@@ -0,0 +1,78 @@
|
||||
# Training Report
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Training Report |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | รายงานอบรม (Training Report) |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Preparation date | 17/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Prepared by | คุณอภิรัชต์ สุภัทรประทีป — Project Manager |
|
||||
| Status | Final as a status report — **no training session has been conducted**; see Section 1 |
|
||||
|
||||
## 1. Disclosure
|
||||
|
||||
At report preparation (17/08/26), no user-training session has taken place for BRN WMS. There is no repository or Git evidence of a training event (no scheduling record, attendance list, or evaluation). Consistent with the project's evidence discipline, this record defines the **planned** training scope rather than fabricating a session, attendees, or satisfaction scores.
|
||||
|
||||
## 2. Planned training information
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
|---|---|
|
||||
| วันที่อบรม (Date) | Not yet scheduled |
|
||||
| สถานที่ (Location) | Not yet determined |
|
||||
| วิทยากรผู้สอน (Trainer) | ธนกร สถิตวิทยากุล (Developer / System Analyst); no dedicated trainer role is currently assigned |
|
||||
| ผู้จัดโครงการอบรม (Organizer) | คุณอภิรัชต์ สุภัทรประทีป (Project Manager) |
|
||||
| จำนวนผู้เข้าอบรม (Expected attendance) | Not yet determined — expected to include Owner/Admin, Staff, and Viewer role representatives per company |
|
||||
|
||||
## 3. Planned curriculum
|
||||
|
||||
Derived from the Software User Documentation (work product 18):
|
||||
|
||||
| No. | Topic |
|
||||
|---:|---|
|
||||
| 1 | Accessing the system and role-based access overview |
|
||||
| 2 | Dashboard orientation |
|
||||
| 3 | Master data setup (warehouse, storage/bin, product, contact) |
|
||||
| 4 | Inventory and warehouse operations (stock-in, stock-out, transfer, barcode) |
|
||||
| 5 | Sales workflow (quotation → order → invoice → return) |
|
||||
| 6 | Purchasing workflow (request → order → invoice → supplier return) |
|
||||
| 7 | Finance and accounting (receipts, payments, journals, GL) |
|
||||
| 8 | Document numbering and status lifecycle |
|
||||
| 9 | Notifications |
|
||||
| 10 | Reports (filter, view, print, export) |
|
||||
|
||||
## 4. Result
|
||||
|
||||
No result to report — training has not yet occurred. This section will be completed with actual attendance, evaluation, and feedback once a session is held.
|
||||
|
||||
## 5. Recommendation
|
||||
|
||||
Schedule training after Test Report execution (work product 16) and before the customer validation session (work product 22), so trained users can meaningfully participate in validation walkthroughs.
|
||||
|
||||
## 6. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Role: Developer / System Analyst
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: กรรมการผู้จัดการ
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
@@ -0,0 +1,136 @@
|
||||
# SDLC Documentation Handoff
|
||||
|
||||
> **Current project status as of 17/08/26:** The Project Sponsor approved CH-004, revising the project period to 05/01/26–24/08/26 while retaining 14/08/26 as the original baseline. Closure activities are scheduled within the revised window.
|
||||
|
||||
## 1. What we just built
|
||||
|
||||
This repository is preparing a full ISO/IEC 29110 Basic Profile work-product set for **BRN WMS**, a browser-based multi-company/multi-warehouse management system (PHP + two MariaDB databases + Node.js/Socket.IO real-time/scheduler services).
|
||||
|
||||
- Project code: `200-WMS-26-001-00`
|
||||
- Project name: `BRN WMS` / `โครงการพัฒนาระบบบริหารจัดการคลังสินค้า`
|
||||
- Approved project period: `05/01/26–24/08/26` (original baseline: `05/01/26–14/08/26`)
|
||||
- All work products live under `sdlc/`, organized as `1-PM Process (10 Work Product)/`, `2-SI Process (12 Work Product)/`, `3-Other Document/`
|
||||
|
||||
**Reference package**: `/mnt/c/Users/TL/Documents/brn-ISO29110` (Windows: `C:\Users\TL\Documents\brn-ISO29110`) is an earlier, completed ISO 29110 project for the *same company* (project code `200-TAS-25-001-00`, a corporate website project). It's used as the structural/stylistic template — match its work-product structure, wording, and print layout as closely as practical, but never copy its project facts. BRN WMS facts and Git evidence always take precedence. Two roles were deliberately carried over as the same real people, because the Project Sponsor and Project Manager are already confirmed identical across both projects (see Section 2).
|
||||
|
||||
**End-to-end status**: every one of the 22 canonical ISO 29110 work products (PM 1–10, SI 11–22) plus all 5 `3-Other Document` items now has a complete Markdown draft — 42 controlled files total. Nothing under `sdlc/` is empty. This was built in stages this session:
|
||||
|
||||
1. PM 1–5 (Statement of Work, Project Plan ×3, 13 Progress Status Records, Correction Register, Acceptance Report) — completed earliest, previously had HTML/PDF too (now deleted, see Section 2).
|
||||
2. PM 6–10 (Change Report, Meeting Record, Software Configuration, Project Repository, Project Repository Backup) — Change Report and Meeting Record were split into one file per instance (4 each) after explicit discussion, matching the example's per-document convention rather than a single register.
|
||||
3. SI 11–22 (SRS through Validation Result) — traced at Customer-Requirements granularity (34 requirements: FR-001–024, NFR-001–010), not the example's much finer CRUD-button granularity, since BRN WMS is a far larger system (31 backend classes vs. the example's ~6 modules).
|
||||
4. `3-Other Document` (List of Evidence, Stakeholder Register, Project Charter Report, Traceability Record Table, Training Report) — matches the example's 5-item roster, with two deliberate deviations explained in Section 4.
|
||||
5. Several rounds of consistency auditing and role/content corrections — see Section 2 for what was found and fixed.
|
||||
|
||||
## 2. Current working status / files edited
|
||||
|
||||
### Document completion state
|
||||
|
||||
| Area | State |
|
||||
|---|---|
|
||||
| PM 1–5 (Statement of Work; Work Schedule; Software Project Plan; Customer Requirements; 13 Progress Status Records; Correction Register; Acceptance Report) | Markdown complete. **All 19 HTML files and the exported PDF package were deleted 17/08/26** at the user's explicit direction (see below) — every file needs re-export from its current `.md` via VS Code Markdown PDF, HTML fine-tuning, then re-print to PDF. |
|
||||
| PM 6–10 (Change Report ×4, Meeting Record ×4, Software Configuration, Project Repository, Project Repository Backup) | Markdown complete. HTML/PDF never yet produced. |
|
||||
| SI 11–22 (SRS, Software Design, Traceability Record, Software Components, Test Cases, Test Report, Software, User Documentation, Product Operation Guide, Maintenance Documentation, Verification Results, Validation Result) | Markdown complete. HTML/PDF never yet produced. |
|
||||
| `3-Other Document` (List of Evidence, Stakeholder Register, Project Charter Report, Traceability Record Table, Training Report) | Markdown complete. HTML/PDF never yet produced. |
|
||||
|
||||
### Corrections and additions made this session (why the HTML above is stale/missing)
|
||||
|
||||
**Roles added** — two people added to the confirmed roster, both at the user's explicit direction:
|
||||
- **ปริญ งามขำ**, QA / Tester — independent of the Developer, now responsible for Test Cases (WP15), Test Report (WP16), and Validation Result (WP22). Added because the project previously had no independent tester (self-testing by the developer).
|
||||
- **คุณเยาวลักษณ์ บางชมภู**, Document Control — carried over from the example reference project's identical role, on the same basis the Sponsor and PM were already carried over (same company, same people). Not yet performed any actual document review — being named ≠ work being done (see evidence discipline, Section 4).
|
||||
|
||||
Both were propagated to: `SDLC_DOCS.md` roster (below), Customer Requirements Section 3, Stakeholder Register, Software Project Plan (Organization table + new headcount table), and the relevant SI work products.
|
||||
|
||||
**Traceability Record (WP13) — two real gaps found and fixed:**
|
||||
1. Added a "Correction/Change reference" column to the 34-row requirement matrix, plus a new Section 5 reverse cross-reference table (every one of the 29 Correction Register entries and 4 Change Report entries → its Git commit → the requirement(s) it affects). 18 of 34 requirements now show at least one link. `CoR-010` is explicitly left unresolved (no recorded cause in the original correction) rather than guessed.
|
||||
2. Cross-checked every ID cited (Req ID, SRS ID, Design Unit ID, Test Case ID, Correction ID) against its source document, and every Git commit hash against real `git log`. Found zero phantom/invented references, but found 15 SRS IDs and 1 Design Unit ID (`UN12`, `StockTablesTrait`) that existed in WP11/WP12 but weren't linked to any requirement row — now linked. 3 SRS items are noted as intentionally cross-cutting rather than forced into one row.
|
||||
|
||||
**Correction Register (WP4)**: 10 "Git evidence" citations were truncated/paraphrased instead of verbatim commit subjects — tightened to exact `git log` text. No content/decision changed, just accuracy.
|
||||
|
||||
**Acceptance Report (WP5)**: Sections 3, 4, 5, and 7 were stale, still describing SI 11–22 as "Not yet completed" from before those work products existed. Refreshed to show them as drafted-but-unverified. The "Acceptance pending" decision itself is unchanged. Added an explicit status callout (see top of this file) so an auditor sees the current state immediately rather than inferring it from scattered remarks.
|
||||
|
||||
**Work Schedule**: verification, validation, test execution, and UAT were subsequently confirmed complete by the project user on 17/08/26; the controlled result records now identify this as retrospective user-confirmed evidence.
|
||||
|
||||
**Software Project Plan** — after actually reading the example's full PDF (not just headings), found 5 real structural gaps and closed them (doc grew from 17 to 18 top-level sections):
|
||||
1. New **Section 6, "Software development lifecycle methodology"** — deliberately does *not* copy the example's "Waterfall" claim; Git evidence shows continuous incremental delivery instead (features and security fixes interleaved throughout, not phase-separated), and the document says so.
|
||||
2. New **Section 8.1, "Human resources and effort estimate"** — states headcount (1 person per role) and calendar-duration-by-phase, and explicitly states why no man-day effort figure is given: no time-tracking evidence exists, so one is not fabricated (same treatment as budget, below).
|
||||
3. New **Section 8.5, "Computer and equipment resources"** — discloses no equipment inventory exists rather than inventing one.
|
||||
4. New **Section 11.1, "Contingency actions for non-completed tasks."**
|
||||
5. New **Section 12.2, "Quality criteria and evaluation methods"** — cross-references existing SRS/NFR content instead of duplicating it.
|
||||
6. Also added **Section 16.1/16.2**, stating BRN WMS's actual file-naming and version convention explicitly in the deliverable itself (previously this only lived in this handoff file) — see Section 4 for the convention itself.
|
||||
|
||||
**Progress Status Record 13** (the last of the 13): added a note explaining why its reporting period (15/08/26–17/08/26) falls after the agreed project boundary (14/08/26) on purpose — it documents Tasks 5.1/5.2 running past their planned finish date, i.e. it's the evidence trail for the closure overrun, not a new phase.
|
||||
|
||||
**List of Evidence, Verification Results, Project Repository (Backup), Product Operation Guide**: each got the same-day status callout / role-name / disclosure updates described above where applicable.
|
||||
|
||||
**Budget**: deliberately **not disclosed** anywhere (Project Charter Report says so explicitly) — no contemporaneous budget record exists, so no figure is fabricated, unlike the example's ฿350,000 breakdown.
|
||||
|
||||
**Database backup**: developer-reported as a daily `mysqldump` script, output stored off-server with a retention policy — real information, but schedule/location/retention specifics and restoration testing are still open (Product Operation Guide item OP-001; Project Repository Backup items BK-001/BK-002).
|
||||
|
||||
### Existing roles (confirmed roster)
|
||||
|
||||
| Person | BRN WMS role |
|
||||
|---|---|
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Customer Representative / Authorized Approver; Managing Director |
|
||||
| คุณอภิรัชต์ สุภัทรประทีป | Project Manager |
|
||||
| ธนกร สถิตวิทยากุล | Developer / System Analyst |
|
||||
| ปริญ งามขำ | QA / Tester — added 17/08/26, independent of the Developer |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control — added 17/08/26, carried over from the example project's same role/person, same company |
|
||||
|
||||
Rule: the developer must never be presented as the independent approver of their own document. Use the Project Manager or Sponsor for review/approval per the example and available evidence. Do not invent additional named people — use `TBD` when a role is genuinely required but unassigned (currently none are TBD; all confirmed roles above are filled).
|
||||
|
||||
### Naming, date, and version conventions
|
||||
|
||||
- Display dates as Gregorian `DD/MM/YY` (e.g. `09/03/26`); filenames use compact Buddhist-calendar dates (e.g. `25690105`).
|
||||
- Filename pattern: `[Project code] [Document name][ - distinguishing suffix if multi-instance] [YYYYMMDD Buddhist] V[version]`.
|
||||
- **Deviation from the example, on purpose**: do not append author initials (example uses `...V1.0 ApS.pdf`; BRN WMS does not).
|
||||
- **Deviation from the example, on purpose**: no `0.1`/`0.2` Draft staging — documents release directly at `V1.0` once complete. "Final" is document-control status, not proof of signature.
|
||||
- Git-supported implementation begins `19/02/26`; development substantially complete `29/05/26`; stabilization evidence `03/08/26`; agreed completion boundary `14/08/26`.
|
||||
|
||||
### HTML formatting decisions (for the fine-tuning step, once HTML exists)
|
||||
|
||||
- Statement of Work: A4 portrait formal letter; BRN emblem, company name/address, blue title band, signature area on the final page.
|
||||
- Work Schedule: A4 landscape spreadsheet; dark-blue document bar, dense grid, repeated headers, separate approval page.
|
||||
- Software Project Plan: A4 portrait multi-page; corporate header, blue section bars, controlled tables, approval page.
|
||||
- Use `app/assets/images/brn-document-header-left.png` (derived from `app/assets/images/brn-document-header.png`) in every generated SDLC HTML document; render the blue/grey title band in HTML per-document. Never use the `BRN WMS` product logo as the company logo.
|
||||
- Preserve the header image's aspect ratio — `25mm` height corresponds to its approved width; don't change one dimension independently. Keep the title band right-aligned.
|
||||
- Document-control tables: dark-blue header row/white text, light-blue label column, thin grey borders, consistent padding.
|
||||
- Light blue for item/section headers only inside Customer Requirements — don't touch the corporate title band styling.
|
||||
- Tables: prefer `table-layout: auto`; ID/status columns `width: 1%` + `white-space: nowrap`; description/value columns take the rest. Don't force unnecessary width.
|
||||
- Chrome Print Preview: A4, Default/100% scale, Background graphics enabled. Landscape only where required (currently just Work Schedule).
|
||||
- Software Design's Use Case/Component/Deployment diagrams and representative UI screenshots get added at the HTML stage, not in Markdown.
|
||||
- Do not use `scripts/format_progress_status_html.php` — rejected earlier as less useful than direct per-document HTML formatting.
|
||||
|
||||
## 3. Next immediate tasks
|
||||
|
||||
1. Re-export PM 1–5 to HTML (all deleted 17/08/26), then convert PM 6–10, SI 11–22, and `3-Other Document` to HTML for the first time — all via VS Code Markdown PDF (user-driven step).
|
||||
2. AI fine-tunes each generated `.html` to A4 print layout per the conventions in Section 2 — reapply PM 1–5's previously-established per-document layouts (they were deleted, not the decisions), match the example's per-document form for Change Report/Meeting Record, match the example's table/layout style for SI documents that have an example equivalent, and use shared document-control conventions for documents with no example equivalent (Software Components, Software, Maintenance Documentation, Project Repository, Project Repository Backup, and all `3-Other Document` items except where the example is deliberately not duplicated — see Traceability Record Table's Deviation note).
|
||||
3. User prints each finished HTML to PDF and re-exports the PM 1–5 PDF package to `C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product)`, replacing the stale copies there.
|
||||
4. Independently confirm the `backup` Git remote is actually in sync (currently developer-reported only) and perform a restoration check (BK-001, BK-002).
|
||||
5. Provision a staging/UAT environment (none currently exists) and execute the 34 defined test cases with ปริญ งามขำ (QA/Tester); record results in the Test Report — currently 34 of 34 passed (user-confirmed).
|
||||
6. Schedule a customer validation session with the Project Sponsor against the 12 scenarios in Validation Result — currently 12 of 12 passed (user-confirmed).
|
||||
7. Obtain an independent Round-2 review of Verification Results — Round 1 is a self-review by the document preparer only.
|
||||
8. Record the `mysqldump` backup's exact schedule, off-server destination, and retention period in a controlled reference (Product Operation Guide item OP-001).
|
||||
9. Schedule and conduct user training (a planned curriculum already exists in the Training Report; no session has occurred).
|
||||
10. Do not restore the legacy `200-TAS-*` PDFs that were cleared from the completed-package PM 6–8 folders on 17/08/26 — populate those folders only with BRN WMS work products.
|
||||
|
||||
## 4. Architectural constraints and decisions
|
||||
|
||||
### Application scope (as reflected in the SDLC documents)
|
||||
|
||||
BRN WMS covers: multi-company/role-based access; inventory and warehouse operations (stock in/out/transfer, lot/serial/expiry, barcode); sales (quotation/order/invoice/return); purchasing (request/order/invoice/supplier-return); finance (receipts/payments); accounting (chart of accounts, journals, GL); reporting; controlled document numbering; Node.js/Socket.IO notifications and scheduled jobs; Docker Compose or manual LAMP deployment. Two MariaDB databases: `wms` (identity/company) and `wms2` (WMS/accounting). 31 PHP manager classes under `app/assets/utils/classes/`.
|
||||
|
||||
### Evidence discipline (the single most important working rule)
|
||||
|
||||
- Never claim a test, meeting, verification, validation, or acceptance occurred unless there is real evidence (a Git commit, or an explicit developer/user statement) — always disclose when something is reconstructed or still pending rather than presenting it as contemporaneous or complete.
|
||||
- Status fields default to "pending" / "not yet executed" / "TBD" until real evidence exists. Don't flip them to "complete"/"passed" just because documentation work finished — documentation completeness and activity completeness are different things (this came up explicitly: the project stays WIP for exactly this reason, confirmed by the user after discussing ISO surveillance-audit use).
|
||||
- Reconstructed planning activities (most of this project, since documentation was written after implementation) are acceptable **only when transparently labeled as reconstructed**.
|
||||
- Never fabricate a figure with no evidentiary basis (budget, effort in man-days, equipment inventory) — state plainly that it isn't disclosed/available instead. This has been applied consistently three times: Project Charter budget, Software Project Plan effort, Software Project Plan equipment.
|
||||
- When restating the example package's content (methodology, structure), don't just copy it if BRN WMS's actual evidence contradicts it — e.g., the example says "Waterfall," BRN WMS's Git history shows incremental/evolutionary delivery, so the SPP says the latter and explains why.
|
||||
- Cross-document consistency matters more than making things look finished: verify every cited ID/commit hash actually exists in its source before trusting it. This class of check found and fixed real gaps twice this session (Traceability Record's ID linkage, Correction Register's commit-message accuracy) — worth repeating periodically, e.g. before major HTML/PDF export passes.
|
||||
- Avoid unnecessary duplication of the same data across documents where two copies could drift out of sync — e.g., the Other Document "Traceability Record Table" is a pointer/summary to the single master matrix in SI work product 13, not a second full copy (explicit user decision after being asked).
|
||||
|
||||
### Repository safety
|
||||
|
||||
- The repository has unrelated, pre-existing application changes — do not revert, reset, or overwrite them while working on SDLC documents.
|
||||
- Limit changes to `sdlc/`, `SDLC_DOCS.md`, and explicitly requested support files.
|
||||
- **`sdlc/` is entirely gitignored** — there is no git safety net for anything under it. Deletions (e.g., the PM 1–5 HTML purge on 17/08/26) are not recoverable via git; treat delete operations there with the same care as anywhere else, but know that `git status`/`git stash` won't help if something goes wrong.
|
||||
Reference in New Issue
Block a user