nok/wms-app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

SDLC docs

Browse Source
This commit is contained in:
Thanakorn
2026-08-17 17:09:27 +07:00
parent 6c39700d74
commit a71366ec9f
49 changed files with 4763 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdlc/2-SI Process (12 Work Product)/11.Software Requirements specification (SRS)/200-WMS-26-001-00 Software Requirements Specification 25690817 V1.0.md
+145
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/12.Software design/200-WMS-26-001-00 Software Design 25690817 V1.0.md
+122
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/13.Traceability record/200-WMS-26-001-00 Traceability Record 25690817 V1.0.md
+147
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/14.Software Components/200-WMS-26-001-00 Software Components 25690817 V1.0.md
+109
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/15Test Cases and Test Procedures/200-WMS-26-001-00 Test Cases and Test Procedures 25690817 V1.0.md
+87
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/16.Test Report/200-WMS-26-001-00 Test Report 25690817 V1.0.md
+113
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/17.Software/200-WMS-26-001-00 Software 25690817 V1.0.md
+57
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/18.Software User Documentation/200-WMS-26-001-00 Software User Documentation 25690817 V1.0.md
+119
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/19.Product Operation Guide/200-WMS-26-001-00 Product Operation Guide 25690817 V1.0.md
+103
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/20.Maintenance Documentation/200-WMS-26-001-00 Maintenance Documentation 25690817 V1.0.md
+80
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/21.Verification Result/200-WMS-26-001-00 Verification Results 25690817 V1.0.md
+86
View File
@@ -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: ___________________________________________________
sdlc/2-SI Process (12 Work Product)/22.Validation Result/200-WMS-26-001-00 Validation Result 25690817 V1.0.md
+77
View File
@@ -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: ___________________________________________________