80 lines
4.6 KiB
Markdown
80 lines
4.6 KiB
Markdown
# Maintenance Documentation
|
||
|
||
| Document field | Value |
|
||
|---|---|
|
||
| Document | Maintenance Documentation |
|
||
| Project | BRN WMS |
|
||
| Project code | 200-WMS-26-001-00 |
|
||
| Title | System Maintenance Manual Document |
|
||
| Project period | 05/01/26–24/08/26 |
|
||
| Release | 17/08/26 V1.0 |
|
||
| Standard | ISO/IEC 29110 Basic Profile |
|
||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||
| Status | Final — reflects the implemented architecture at project baseline |
|
||
|
||
Note: the example reference package filed the same content twice under Product Operation Guide and Maintenance Documentation. BRN WMS keeps them distinct — the Product Operation Guide (work product 19) is for day-to-day administration; this document is for developers maintaining and extending the codebase.
|
||
|
||
## Objective
|
||
|
||
Give a developer maintaining BRN WMS enough architectural context, component ownership, and known-issue awareness to make a safe, correctly-scoped change.
|
||
|
||
## 1. Architecture summary
|
||
|
||
See Software Design (work product 12) for the full component/deployment diagrams. In summary: PHP presentation + business-logic manager classes → two MariaDB databases (`wms` identity/company, `wms2` WMS/accounting), plus a Node.js real-time/scheduler tier reached only through a secret-protected internal endpoint.
|
||
|
||
## 2. Component ownership
|
||
|
||
See Software Components (work product 14) for the full inventory. When changing behavior, locate the owning manager class first (e.g., stock behavior → `StockManager`/`StockSourceManager`/`StockTablesTrait`; posting/GL behavior → `PostingManager`; document numbering → `DocumentNumberManager`) rather than editing page-level code directly, consistent with NFR-007 (maintainability).
|
||
|
||
## 3. Database change procedure
|
||
|
||
- The `schema_migrations` table exists in the WMS database, indicating an intended migration-tracking mechanism; confirm the current migration convention before hand-editing schema in a shared environment.
|
||
- `setup.php` is the authoritative one-shot schema definition for a fresh environment; any schema change should be reflected there so a new environment matches production.
|
||
- Prefer additive, backward-compatible schema changes; coordinate destructive schema changes through the Change Report.
|
||
|
||
## 4. Configuration points
|
||
|
||
| Area | File(s) | Notes |
|
||
|---|---|---|
|
||
| Database/app config | `app/config.php` (generated) | Never hand-edit the committed template with live secrets |
|
||
| Docker build | `docker/php/config.php.template`, `docker/php/entrypoint.sh` | Change here to affect all container deployments |
|
||
| Node.js services | `nodejs/server.js`, `nodejs/scheduler.js`, `nodejs/ecosystem.config.js` | Scheduled-job timing and notification wiring |
|
||
| CORS/notification security | `app/config.php` (`NODE_EMIT_SECRET`), Node.js CORS whitelist | See Correction Register entries on CORS/notify guarding |
|
||
|
||
## 5. Known issues and defect history
|
||
|
||
The Correction Register (work product 4) is the authoritative known-issue history: 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: Thanakorn Sathitwitayakul
|
||
Role: Developer
|
||
Signature: ______________________________________________
|
||
Date: ___________________________________________________
|
||
|
||
### Reviewed by
|
||
|
||
Name: Apirach Supattaratpateep
|
||
Role: Project Manager
|
||
Signature: ______________________________________________
|
||
Date: ___________________________________________________
|
||
|
||
### Reviewed and authorized by
|
||
|
||
Name: Seri Viriyasakultorn
|
||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||
Position: Managing Director
|
||
Company: B.R.N. Enterprise Co., Ltd.
|
||
Signature: ______________________________________________
|
||
Date: ___________________________________________________
|