# PIAM Warehouse Management - Gap Analysis

**Document Version:** 1.0
**Date Created:** 2025-10-29
**Analysis Type:** Requirements vs Implementation Gap Analysis

---

## Executive Summary

This document provides a comprehensive gap analysis between the warehouse management requirements (as documented in `doc/warehouse.txt`) and the current implementation in the PIAM system. The analysis covers 13 major functional areas with detailed status assessments.

### Overall Status

| Status | Count | Percentage |
|--------|-------|------------|
| ✅ Fully Implemented | 4 areas | ~30% |
| ⚠️ Partially Implemented | 5 areas | ~38% |
| ❌ Not Implemented | 4 areas | ~32% |

---

## Detailed Gap Analysis by Module

### 3.1 การจัดการคลังพัสดุทั่วไป (General Warehouse Management)

#### Status: ⚠️ **Partially Implemented (60%)**

#### ✅ Implemented Features

**3.1.1 โครงสร้างคลังและสถานที่จัดเก็บ (Warehouse Structure)**
- ✅ Main Store and Sub Store hierarchy (`StorageLocation` entity with parent-child relationships)
- ✅ Location details configuration (code, name, type, active status)
- ✅ Separate storage for institution-owned vs consignment stock (`StockOwnershipType` enum)
- ✅ Specific bin location assignment for items
- ✅ Lot control support (`InventoryBalance` with lot number and expiry tracking)
- ✅ API: `WarehouseStructureController` with full CRUD operations
- ✅ Frontend: `warehouse-structure` module with tree view

**3.1.2 การรับพัสดุเข้าคลัง (Goods Receipt)**
- ✅ Integration with procurement module via `PurchaseOrder` linkage
- ✅ Receipt from vendors (`GoodsReceiptNote` entity)
- ✅ Receipt with multiple channels:
  - From suppliers (full implementation)
  - Free goods tracking (landed cost system)
- ✅ API: `GoodsReceiptsController` with workbench and posting
- ✅ Frontend: `warehouse-receiving` module

**3.1.3 การตรวจสอบสินค้าคงคลัง (Stock Inquiry)**
- ✅ Multiple inquiry formats:
  - Stock Card (transaction history per item)
  - Stock Movements (all movements)
  - Stock Summary (aggregate views)
- ✅ Search items and view balance by warehouse
- ✅ Display detailed stock movements
- ✅ Real-time stock card movement tracking
- ✅ Check balance by specific warehouse or all warehouses
- ✅ API: `InventoryInquiryController`
- ✅ Frontend: `inventory-inquiry` module

**3.1.4 การสอบถามยอดคงเหลือ (Balance Inquiry)**
- ✅ View balance data by item
- ✅ Check balance at any point in time (historical and current)
- ✅ Display quantity in base unit and packing unit
- ✅ Visual inventory tools for location-based viewing

**3.1.5 การแจ้งเตือน (Alerts)**
- ⚠️ Partial: Infrastructure exists (min/max levels can be configured) but notification system not implemented

#### ❌ Missing Features

**3.1.2 การรับพัสดุเข้าคลัง**
- ❌ Receipt from sub-warehouse to main warehouse (return flow)
- ❌ Receipt return from departments
- ❌ Explicit "receipt from another warehouse" transaction type

**3.1.4 การสอบถามยอดคงเหลือ**
- ❌ Automatic filtering for:
  - Stock below reorder point
  - Stock below minimum level
  - Stock above maximum level

**3.1.5 การแจ้งเตือน**
- ❌ Low stock alerts
- ❌ Out of stock alerts
- ❌ Insufficient stock warnings during transfer/issue

#### Recommendations
1. Implement stock level alerting system with configurable thresholds
2. Add return receipt flows (from departments, between warehouses)
3. Create dashboard widgets for stock alerts and reorder suggestions

---

### 3.2 การขอเบิกพัสดุ (Internal Requisition)

#### Status: ❌ **Not Implemented (0%)**

#### Required Features (All Missing)

**3.2.1 การสร้างใบขอเบิก (Requisition Creation)**
- ❌ No requisition entity or workflow
- ❌ Cannot create requisition from sub-warehouse to main warehouse
- ❌ Cannot create requisition from department to equipment warehouse
- ❌ No document numbering system for requisitions
- ❌ No urgent/normal priority flags

**3.2.2 การเลือกรายการเบิก (Item Selection)**
- ❌ No item selection for requisition
- ❌ No "Load items below Safety Level" feature
- ❌ No "Load items below Max Level" feature
- ❌ No unit of measure selection (base/packing)

**3.2.3 การอนุมัติใบขอเบิก (Requisition Approval)**
- ❌ No approval workflow
- ❌ No approval authority configuration
- ❌ No approval status tracking
- ❌ No approval audit trail
- ❌ No document lock after approval

**3.2.4 การค้นหาและติดตาม (Search and Tracking)**
- ❌ No requisition search functionality
- ❌ Cannot track requisition by:
  - Document type
  - Source/destination warehouse
  - Document number/date
  - Requesting department

#### Current Workaround

The system currently has:
- ✅ `InternalTransferOrder` which serves a similar purpose but is initiated by the main warehouse, not by the requesting department
- ⚠️ Frontend module `warehouse-requisitions` exists but contains only mock data

#### Gap Impact: **HIGH**

This is a critical workflow gap. In hospital environments, departments should initiate requisitions that are then approved and fulfilled by the central warehouse. The current transfer system is warehouse-centric rather than requisition-centric.

#### Recommendations

**Priority: HIGH - Implement immediately**

1. Create new entities:
   - `InternalRequisition` (header)
   - `InternalRequisitionLine` (line items)
   - `InternalRequisitionStatus` enum (Draft, Submitted, Approved, Rejected, PartiallyFulfilled, Fulfilled, Cancelled)

2. Implement workflow:
   - Department creates requisition (Draft)
   - Submit for approval (Submitted)
   - Warehouse manager approves/rejects (Approved/Rejected)
   - Warehouse creates transfer order from approved requisition (converts to InternalTransferOrder)
   - Track fulfillment status

3. Add APIs:
   - `POST /api/requisitions` - Create requisition
   - `PUT /api/requisitions/{id}` - Edit draft
   - `POST /api/requisitions/{id}/submit` - Submit for approval
   - `POST /api/requisitions/{id}/approve` - Approve
   - `POST /api/requisitions/{id}/reject` - Reject
   - `POST /api/requisitions/{id}/create-transfer` - Convert to transfer order
   - `GET /api/requisitions/workbench` - List requisitions with filtering

4. Integrate with existing `InternalTransferOrder` system for fulfillment

---

### 3.3 การจ่ายพัสดุออกจากคลัง (Stock Issue/Dispense)

#### Status: ❌ **Not Implemented (10%)**

#### ✅ Implemented Features

**Partial infrastructure:**
- ✅ `InventoryTransaction` entity supports "Issue" transaction type
- ✅ `InternalTransferOrder` has picking workflow that reduces stock

#### ❌ Missing Features

**3.3.1 การดำเนินการจ่ายพัสดุ (Issue Operations)**
- ❌ No direct issue document (separate from transfer)
- ❌ Cannot issue to departments without creating full transfer order
- ❌ No issue quantity adjustment (requested vs actually issued)
- ❌ Cannot create issue without requisition reference

**3.3.2 ระบบอนุมัติใบโอนออก (Issue Approval System)**
- ⚠️ Transfer orders have status workflow but no explicit "Issue Note" approval
- ❌ No automatic stock deduction upon approval (currently deducted on pick confirmation)
- ❌ No specific issue document that can be approved independently

**3.3.3 การค้นหาและเอกสาร (Search and Documents)**
- ❌ Cannot search specifically for "issue documents"
- ❌ No issue document copy functionality
- ❌ No approved issue document search

#### Current Workaround

- The system uses `InternalTransferOrder` for all stock movements, which combines requisition, issue, and transfer concepts into one workflow
- Frontend module `warehouse-issues` exists but is mock only

#### Gap Impact: **MEDIUM-HIGH**

While technically stock can move using transfers, the requirement specifies separate "Issue" documents that:
1. Can be created independently or from requisitions
2. Have their own approval workflow
3. Reduce stock immediately upon approval (not upon picking)
4. Are distinct from transfer orders

#### Recommendations

**Priority: MEDIUM - Implement after requisitions**

Option 1: **Enhance InternalTransferOrder** (Simpler)
- Add `IssuedQuantity` field separate from `QuantityPicked`
- Add approval step that creates inventory transactions immediately
- Add filtering to distinguish "issues" from "transfers"

Option 2: **Create Separate Issue Document** (Matches requirements exactly)
- Create `StockIssueNote` entity
- Link to `InternalRequisition` (optional)
- Approval workflow that creates `InventoryTransaction` immediately
- Separate from physical picking/transfer workflow

Recommended: **Option 2** - Better separation of concerns and matches hospital workflow

---

### 3.4 การรับพัสดุเข้าคลังย่อย (Sub-Warehouse Receipt)

#### Status: ❌ **Not Implemented (5%)**

#### ✅ Implemented Features

**Minimal infrastructure:**
- ✅ `InternalTransferOrder` with `InTransit` status suggests goods in transit
- ✅ `InventoryTransaction` can record receipts at destination

#### ❌ Missing Features

**3.4.1 การดำเนินการรับของ (Receipt Operations)**
- ❌ No sub-warehouse receipt document entity
- ❌ Cannot search receipt documents by:
  - Document type
  - Source/destination warehouse
  - Document number/date
- ❌ No "received quantity" confirmation by receiving department
- ❌ No discrepancy handling (ordered vs shipped vs received)

**3.4.2 ระบบอนุมัติใบรับของโอน (Receipt Approval)**
- ❌ No receipt approval workflow
- ❌ No document lock after approval
- ❌ Stock not added to sub-warehouse upon receipt confirmation

**3.4.3 ผลลัพธ์การบันทึก (Receipt Results)**
- ❌ Stock not increased in sub-warehouse upon receipt
- ❌ Delivery status not updated to "Received"
- ❌ No "pending receipt" queue for receiving departments

#### Current Situation

- `InternalTransferOrder` goes from Released → Picking → InTransit → **Completed**
- The "Completed" status implies receipt but there's no explicit receipt confirmation by the receiving department
- Stock is likely increased when status changes to Completed, but no formal receipt document exists

#### Gap Impact: **MEDIUM**

The receiving department should actively confirm receipt and record any discrepancies. This is important for:
1. Accountability (who received what when)
2. Discrepancy resolution (damaged goods, wrong quantities)
3. Audit trail

#### Recommendations

**Priority: MEDIUM**

1. Create new entity: `SubWarehouseReceiptNote`
   - Links to `InternalTransferOrder`
   - Status: Draft, Posted
   - ExpectedQuantity, ReceivedQuantity, DiscrepancyReason
   - ReceivedByEmployee, ReceivedDate

2. Workflow:
   - When `InternalTransferOrder` reaches `InTransit` status, create draft `SubWarehouseReceiptNote`
   - Receiving department opens receipt note, confirms quantities
   - Post receipt → creates inventory transaction → updates transfer status to Completed

3. Add to `warehouse-sub-receipts` module (currently mock)

---

### 3.5 การโอนย้ายพัสดุระหว่างคลัง (Inter-Warehouse Transfer)

#### Status: ⚠️ **Partially Implemented (70%)**

#### ✅ Implemented Features

**3.5.1 การโอนย้าย (Transfer Operations)**
- ✅ Support transfer between locations (`InternalTransferOrder`)
- ✅ Transfer between warehouses and departments
- ✅ Borrow/return workflows (can be modeled with document type)

**3.5.2 การบันทึกข้อมูล (Data Recording)**
- ✅ Document type specification (via status or could add type enum)
- ✅ Source and destination warehouse
- ✅ Requesting department reference
- ✅ Document date tracking
- ✅ Employee assignment (picker)
- ✅ Bin location scanning workflow
- ✅ Lot number selection
- ✅ Actual quantity confirmation

**Additional Features:**
- ✅ Full picking workflow with queue (`warehouse-picking` module)
- ✅ Pick instructions with suggested locations
- ✅ Transit location support
- ✅ Status tracking: Draft → Released → Picking → InTransit → Completed

#### ❌ Missing Features

**3.5.1 การโอนย้าย**
- ❌ No explicit "borrow" and "return" document types (could use single transfer type)
- ❌ No barcode scanning integration (UI exists but no device integration)

**Frontend Gaps:**
- ❌ `warehouse-transfers` module exists but only has mock data
- ✅ `warehouse-picking` module is fully implemented
- ⚠️ No UI for transfer order creation (only picking interface exists)

#### Gap Impact: **LOW-MEDIUM**

The core transfer engine is solid. Main gaps are:
1. Transfer order **creation** UI (requests come from somewhere)
2. Document type taxonomy (borrow, return, transfer, move)

#### Recommendations

**Priority: LOW - Minor enhancements**

1. Implement `warehouse-transfers` module for transfer order creation:
   - Browse existing transfers
   - Create new transfer (if not from requisition)
   - View transfer history and status

2. Add `TransferType` enum:
   - StandardTransfer
   - BorrowOut
   - BorrowReturn
   - Emergency
   - Replenishment

3. Add transfer analytics dashboard

---

### 3.6 การปรับปรุงยอดพัสดุ (Stock Adjustment)

#### Status: ❌ **Not Implemented (10%)**

#### ✅ Implemented Features

**Infrastructure only:**
- ✅ `InventoryTransaction` entity has `Adjustment` transaction type
- ✅ Can technically record adjustment transactions
- ✅ Lot number and expiry date can be specified

#### ❌ Missing Features

**3.6.1 การปรับปรุงยอด (Adjustment Operations)**
- ❌ No stock adjustment document/form
- ❌ Cannot adjust balance with notes/reason
- ❌ No stock count adjustment import
- ❌ No cycle count adjustment posting
- ❌ No cost adjustment functionality
- ❌ No adjustment by import (increase)
- ❌ No adjustment by write-off (decrease)

**3.6.2 ประเภทการปรับยอด (Adjustment Types)**
- ❌ No adjustment reason types:
  - Internal Use
  - Damaged
  - Expired
  - Stock Count Adjustment
  - Theft/Loss
  - Found/Surplus
- ❌ No adjustment reason master data

**3.6.3 การดำเนินการ (Operations)**
- ❌ No UI to search and select items for adjustment
- ❌ No lot selection for adjustment
- ❌ Cannot specify positive or negative adjustment quantity
- ❌ No user permission control for adjustments
- ❌ No adjustment approval workflow

#### Current Situation

- `CycleCountTask` approval creates adjustments automatically (good!)
- But there's no way to create ad-hoc adjustments for damage, expiry, found items, etc.
- Frontend module `warehouse-adjustments` exists but is mock only

#### Gap Impact: **HIGH**

Stock adjustments are critical for:
1. Recording damaged/expired goods
2. Correcting data entry errors
3. Recording theft or loss
4. One-time corrections
5. Recording found items

Without this, inventory accuracy cannot be maintained outside of cycle counting.

#### Recommendations

**Priority: HIGH - Implement soon**

1. Create entities:
   - `StockAdjustment` (header)
   - `StockAdjustmentLine` (line items)
   - `StockAdjustmentReason` (master data)
   - `StockAdjustmentStatus` enum (Draft, Posted)

2. Fields:
   - AdjustmentType (Increase, Decrease)
   - ReasonCode (lookup to reasons master)
   - Item, Location, Lot, Expiry
   - CurrentQuantity (display only)
   - AdjustmentQuantity (signed value: + or -)
   - NewQuantity (calculated)
   - UnitCost (for cost adjustments)
   - Notes

3. Workflow:
   - Create adjustment (Draft)
   - Add line items with reasons
   - Post → creates `InventoryTransaction` with type `Adjustment`
   - Update `InventoryBalance`

4. Permissions:
   - Control who can create adjustments
   - Control who can post adjustments (may require approval for large adjustments)

5. Implement `warehouse-adjustments` module frontend

---

### 3.7 การตรวจนับสต็อก (Cycle Counting)

#### Status: ✅ **Fully Implemented (95%)**

#### ✅ Implemented Features

**3.7.1 การบริหารจัดการแผนการตรวจนับ (Plan Management)**
- ✅ Warehouse managers can create count plans (`CycleCountPlan`)
- ✅ Multiple plan types supported (by frequency, location, item classification)
- ✅ Plan includes locations and frequency configuration
- ✅ Plans can be activated/deactivated

**3.7.2 การดำเนินการตรวจนับ (Count Execution)**
- ✅ System generates count tasks automatically from plans
- ✅ Tasks assigned to employees
- ✅ Mobile/tablet ready workflow
- ✅ Blind count support (expected quantity hidden)
- ✅ Employee scans location and items
- ✅ Employee enters counted quantity
- ✅ QR code support mentioned (barcode scanning infrastructure)

**3.7.3 การตรวจสอบและอนุมัติผลต่าง (Variance Approval)**
- ✅ System generates variance report (calculated from expected vs counted)
- ✅ Warehouse manager reviews variance report
- ✅ Approval workflow (`CycleCountTask` with PendingApproval status)
- ✅ System creates adjustment transaction automatically upon approval
- ✅ Reports available for count plans and results

**Technical Implementation:**
- ✅ API: `CycleCountController` with full CRUD and workflow operations
- ✅ Frontend: `warehouse-cycle-count` module fully implemented
- ✅ Services: `CycleCountService` with complete business logic
- ✅ Entities: `CycleCountPlan`, `CycleCountPlanLocation`, `CycleCountTask`, `CycleCountResult`

#### ⚠️ Minor Gaps

**3.7.2 การดำเนินการตรวจนับ**
- ⚠️ QR code scanning mentioned but actual barcode scanner integration may need testing
- ⚠️ Mobile app UI may need optimization for tablet devices

**3.7.3 Reporting**
- ⚠️ Standard count reports exist but may need additional report formats

#### Gap Impact: **VERY LOW**

This module is nearly complete and well-implemented.

#### Recommendations

**Priority: LOW - Nice to have**

1. Add more variance analysis reports:
   - Variance by employee (accuracy tracking)
   - Variance by location (problematic areas)
   - Variance by item (frequently miscounted items)

2. Add variance tolerance configuration:
   - Auto-approve variances within X%
   - Require supervisor approval for variances above Y%

3. Add cycle count scheduling automation:
   - Automatically generate tasks based on plan frequency
   - Email notifications to assigned employees

---

### 3.8 การจัดการข้อมูลและรายงานคลัง (Warehouse Data Management & Reporting)

#### Status: ⚠️ **Partially Implemented (40%)**

#### ✅ Implemented Features

**3.8.1 การกำหนดรูปแบบเอกสาร (Document Format Configuration)**
- ✅ Document numbering can be configured (standard .NET pattern)
- ⚠️ May need auto-numbering service implementation verification

**3.8.2 เอกสารแบบฟอร์ม (Document Forms)**
- ⚠️ Printing capability depends on frontend implementation
- ✅ API provides data for all required documents

**Available via API:**
- ✅ Transfer orders (InternalTransferOrder)
- ✅ Receipt notes (GoodsReceiptNote)
- ✅ Cycle count reports
- ✅ Balance reports
- ⚠️ Issue notes (not implemented)
- ⚠️ Requisitions (not implemented)
- ⚠️ Adjustment notes (not implemented)
- ⚠️ Borrow/return slips (no specific document type)

#### ❌ Missing Features

**3.8.2 เอกสารแบบฟอร์ม**
Print-ready documents for:
- ❌ Issue slips
- ❌ Requisition forms
- ❌ Adjustment notes
- ❌ Borrow/return slips
- ❌ Stock balance sheets
- ❌ Material withdrawal slips

**3.8.3 รายงานต่างๆ (Various Reports)**
Most standard reports not implemented:
- ❌ Receipt inspection report
- ❌ Receipt-issue inspection report
- ❌ Material issue report by department and type
- ❌ Over-standard requisition report
- ❌ Inventory by category and warehouse report
- ❌ Pending receipt report
- ❌ Vendor invoice receipt report
- ❌ Material movement report
- ❌ Inventory summary report

**3.8.4 Balance and Movement Reports**
- ❌ Current inventory status report
- ❌ Minimum stock at reorder point report
- ❌ Receipt-issue-balance report
- ❌ Period-to-period comparison report
- ❌ Last purchase price report
- ❌ Equipment inventory and balance report

#### Current Situation

- Frontend module `warehouse-reports` exists but is mock only
- Raw data is available via APIs but no formatted reports
- No report generation engine implemented

#### Gap Impact: **MEDIUM-HIGH**

While operations can function, **management reporting and compliance** require these standard reports.

#### Recommendations

**Priority: MEDIUM - Implement after core operations**

**Phase 1: Critical Operational Reports**
1. Daily stock balance report
2. Stock movement report (receipt/issue/balance)
3. Pending receipt report
4. Low stock alert report

**Phase 2: Compliance Reports**
5. Receipt inspection report
6. Issue by department report
7. Inventory summary report

**Phase 3: Analytics**
8. Stock turnover analysis
9. Period comparison reports
10. ABC analysis reports

**Implementation Approach:**
- Use reporting framework (e.g., Crystal Reports, SSRS, or custom with libraries like QuestPDF)
- Create report templates for each required report
- Add report generation endpoints to API
- Add report viewer/downloader in `warehouse-reports` module

---

### 3.9 คลังเวชภัณฑ์และยา (Pharmacy Warehouse)

#### Status: ⚠️ **Partially Implemented (30%)**

#### ✅ Implemented Features

**3.9.1 การควบคุมสต็อกเวชภัณฑ์และยา**
- ✅ Item master supports medical items (via category)
- ✅ Real-time inventory tracking (`InventoryBalance`)
- ✅ Search drugs/medical supplies and view balance
- ✅ Stock data by location/sub-warehouse
- ⚠️ Integration with procurement exists
- ❌ Integration with HIS/sales system not verified

**3.9.2 การจัดการวันหมดอายุ**
- ✅ Expiry date tracking in `InventoryBalance` and `InventoryTransaction`
- ✅ Lot/batch tracking fully supported
- ⚠️ Expiry alert system not implemented

**3.9.3 การจัดการข้อมูลยาและเวชภัณฑ์**
- ⚠️ Item master supports basic fields but may need pharmacy-specific extensions:
  - ❌ Trade name (may need separate field)
  - ❌ Government accounting code
  - ❌ Insurance scheme codes
  - ❌ OPD price
  - ❌ IPD price
  - ❌ Central drug price

**3.9.4 การจัดการขอเบิกและจ่ายยา**
- ⚠️ Uses generic transfer system
- ❌ No pharmacy-specific requisition workflow
- ❌ No pharmacy-specific issue process

**3.9.5 การค้นหาเอกสาร**
- ✅ Basic document search exists
- ⚠️ Pharmacy-specific documents not separated

**3.9.6 การตั้งค่าและการจัดการ**
- ✅ Min/max levels can be configured (Item master has min/max stock fields)
- ⚠️ Master data for pharmacy:
  - ✅ Units of measure (UOM entity exists)
  - ❌ Stock take groups (no specific entity)
  - ✅ Vendors/Suppliers (Supplier entity exists)
  - ✅ Departments (Department entity exists)
  - ✅ User permissions (handled by identity system)
  - ⚠️ Min levels per location (needs verification)
  - ❌ Adjustment reason codes (not implemented)
  - ❌ Pharmaco category hierarchy (no specific classification)

**3.9.7 รายงานคลังเวชภัณฑ์และยา**
Most pharmacy reports not implemented:
- ❌ Drug/medical receipt-issue inspection report
- ❌ Near-expiry drug report
- ❌ Drug receipt report
- ❌ Pending receipt report
- ❌ Vendor invoice report
- ❌ Drug/medical inventory summary
- ❌ Drug receipt to warehouse report
- ❌ Medical supplies pending delivery report
- ❌ Purchase requisition forms
- ❌ Purchase order form
- ❌ Receipt memo and accounting record

#### Current Situation

- Generic warehouse system can handle pharmacy items but lacks:
  1. Pharmacy-specific workflows
  2. Pharmacy-specific pricing (OPD/IPD/insurance)
  3. Drug-specific master data fields
  4. Pharmacy compliance reports
  5. Integration with hospital information system (HIS)

- Frontend module `pharmacy-warehouse` exists but is mock only
- Special API `MedicalStockInquiryController` exists for medical items

#### Gap Impact: **HIGH** (if this is a hospital system)

Pharmacy management has specialized requirements for:
1. Regulatory compliance
2. Pricing schemes (OPD/IPD/insurance)
3. Near-expiry tracking and alerts
4. Narcotic/controlled substance handling
5. HIS integration for prescription fulfillment

#### Recommendations

**Priority: HIGH (if hospital/medical), MEDIUM (if general inventory)**

**Phase 1: Master Data Enhancement**
1. Extend `Item` entity or create `MedicalItem` entity with:
   - TradeNameThai, TradeNameEnglish
   - GenericName
   - GovernmentAccountingCode
   - IsControlledSubstance, IsDangerousDrug
   - InsuranceSchemeCode (multiple)
   - OpdPrice, IpdPrice, EmployeePrice, CentralDrugPrice
   - PharmacologicalCategory, SubCategory, SubMinorCategory
   - Dosage form, strength, route of administration

2. Create `DrugPriceScheme` entity for multiple pricing levels

**Phase 2: Pharmacy Workflows**
3. Implement pharmacy requisition (different from general requisition)
4. Implement pharmacy issue with prescription tracking
5. Add controlled substance tracking (special approval, quantity limits)

**Phase 3: Alerts and Compliance**
6. Implement near-expiry alerts (7 months, 3 months, 1 month warnings)
7. Implement narcotic/controlled substance reporting
8. Add dangerous drug storage tracking

**Phase 4: Reporting**
9. Implement all pharmacy-specific reports (see 3.9.7 list)

**Phase 5: HIS Integration**
10. API integration with HIS for:
    - Prescription orders
    - Dispensing records
    - Patient drug history

---

### 3.10 การจัดการคลังขั้นสูง (Advanced Warehouse Features)

#### Status: ⚠️ **Partially Implemented (65%)**

#### ✅ Implemented Features

**3.10.1 การจัดการหลายหน่วยนับ (Multiple UOM)**
- ✅ Item supports multiple units of measure
- ✅ UOM entity exists with conversion factors
- ✅ Transactions can specify UOM
- ✅ Automatic unit conversion (need to verify implementation)

**3.10.2 การจัดการ Lot และ Serial Number (Lot & Serial Management)**
- ✅ Full lot management support:
  - `InventoryBalance` tracks by lot number and expiry
  - `GoodsReceiptNoteItemLot` entity for lot receipt
  - `InventoryTransaction` records lot numbers
- ✅ Serial number support:
  - `GoodsReceiptSerialNumber` entity exists
  - Serial tracking for serialized items
- ✅ Lot number can be auto-generated or manual
- ✅ Item can be flagged for lot control and serialization

**3.10.3 การเตรียมการและจัดส่ง (ASN and Shipping)**
- ⚠️ ASN (Advanced Ship Notice) infrastructure:
  - Frontend module `warehouse-asn` exists but is mock only
  - No ASN entity found
  - No ASN import/receive workflow

#### ❌ Missing Features

**3.10.3 การเตรียมการและจัดส่ง**
- ❌ Cannot receive ASN from vendors
- ❌ Cannot use ASN for quick goods receipt
- ❌ No truck arrival notification system
- ❌ No dock door assignment

#### Gap Impact: **LOW-MEDIUM**

Lot and serial tracking is well-implemented, which is critical. ASN is a nice-to-have for high-volume operations.

#### Recommendations

**Priority: LOW - Future enhancement**

**If implementing ASN:**
1. Create `AdvancedShipNotice` entity:
   - Linked to PurchaseOrder
   - VendorReference, ExpectedArrivalDate
   - Status: Sent, Received, Closed
   - Lines collection

2. Create `AdvancedShipNoticeLine` entity:
   - Item, OrderedQuantity, ShippedQuantity
   - Lot numbers and expiry dates (from vendor)
   - Box/pallet information

3. Workflow:
   - Import ASN from vendor (EDI, email, API, manual entry)
   - Review ASN → Create draft GoodsReceiptNote from ASN
   - Receive goods → Compare actual vs ASN → Complete receipt

4. Benefits:
   - Faster receiving (pre-populated data)
   - Discrepancy detection before goods arrive
   - Better warehouse planning (know what's arriving when)

---

### 3.11 งบประมาณและบัญชี (Budget and Accounting Integration)

#### Status: ⚠️ **Partially Implemented (40%)**

#### ✅ Implemented Features

**3.11.1 การเชื่อมโยงงบประมาณ (Budget Integration)**
- ⚠️ `PurchaseOrder` likely has budget tracking (need to verify in procurement module)
- ⚠️ Budget commitment may exist in procurement module
- ❌ Budget tracking by drug/item code not found
- ❌ Budget visualization (charts/graphs) not implemented
- ❌ No budget vs actual report for warehouse operations

**3.11.2 การเชื่อมโยงบัญชี (Accounting Integration)**
- ⚠️ Inventory transactions exist but accounting integration unclear
- ❌ Cannot map multiple GL accounts per warehouse
- ❌ No holding/clearing account functionality
- ❌ No GL account assignment to item categories or warehouses
- ❌ No accounting voucher generation from inventory transactions
- ❌ No cost verification reports

**3.11.3 การจัดการต้นทุน (Cost Management)**
- ✅ Unit cost tracking in `InventoryTransaction`
- ⚠️ Cost calculation method configuration not found
- ⚠️ Return cost calculation (need to verify)
- ⚠️ Landed cost allocation exists (`LandedCostTransaction` entity found!)
- ✅ Cost tracking from receipt to usage

#### Current Situation

**Strengths:**
- Inventory transactions track unit costs
- Landed cost system exists (advanced feature!)

**Weaknesses:**
- No GL integration visible
- No budget tracking at warehouse level
- No standard cost accounting reports

#### Gap Impact: **MEDIUM** (depends on ERP integration requirements)

If PIAM is standalone: **HIGH** - Need accounting integration
If PIAM integrates with external ERP/accounting system: **LOW** - May be handled upstream

#### Recommendations

**Priority: MEDIUM - Depends on system architecture**

**If standalone accounting required:**

**Phase 1: GL Account Mapping**
1. Create `WarehouseGLMapping` entity:
   - Map Warehouse + ItemCategory → GL Accounts
   - InventoryAccount (asset)
   - CostOfGoodsAccount (expense)
   - VarianceAccount (expense)
   - ReturnAccount (asset)

2. Create accounting voucher generation service:
   - Post inventory transactions → generate GL entries
   - Receipt → Debit Inventory, Credit Payable
   - Issue → Debit COGS, Credit Inventory
   - Adjustment → Debit/Credit Variance Account

**Phase 2: Budget Tracking**
3. Add `BudgetAllocation` entity:
   - By ItemCategory or Item
   - By Department
   - By Fiscal year
   - Allocated amount, committed amount, actual amount

4. Budget checking service:
   - Check budget availability before issue/requisition approval
   - Update budget commitments
   - Budget alert when exceeding allocation

**Phase 3: Reporting**
5. Implement cost accounting reports:
   - Cost of goods report
   - Inventory valuation report
   - Budget vs actual report
   - Variance analysis report

**If external ERP integration:**
- Create integration API for:
  - Daily inventory transaction export
  - GL account mapping lookup
  - Budget availability check

---

### 3.12 การบริหารจัดการข้อมูลและการตั้งค่า (Data Management & Configuration)

#### Status: ⚠️ **Partially Implemented (50%)**

#### ✅ Implemented Features

**3.12.1 การตั้งค่าข้อมูลพื้นฐาน (Basic Configuration)**
- ✅ Suppliers can be recorded
- ⚠️ Document type taxonomy may need extension
- ✅ Departments exist
- ✅ VAT configuration likely in system settings
- ⚠️ Procurement method may be in procurement module
- ✅ Document dates tracked

**3.12.2 การกำหนดโครงสร้างงบประมาณ (Budget Structure)**
- ⚠️ Budget structure may be in procurement module
- ❌ Standard price (reference price) configuration not visible
- ❌ Cost center hierarchy not found
- ❌ Program/project/activity structure not found

**3.12.3 การจัดการกรรมการ (Committee Management)**
- ⚠️ May be in procurement module
- ❌ No committee/board member management found in warehouse module

**3.12.4 ระบบอนุมัติเอกสาร (Document Approval)**
- ⚠️ Some documents have approval (cycle count)
- ❌ No universal approval workflow engine
- ❌ Requisition approval not implemented (requisition not implemented)
- ❌ Issue approval limited
- ❌ Adjustment approval not implemented

#### ❌ Missing Features

**Configuration management:**
- ❌ No centralized settings management
- ❌ No document numbering format configuration UI
- ❌ No approval workflow configuration (who approves what)
- ❌ No notification configuration
- ❌ No user role management specific to warehouse operations

**Master data:**
- ❌ No adjustment reason codes
- ❌ No transfer type taxonomy
- ❌ No document status workflow customization

#### Gap Impact: **MEDIUM**

System works with defaults but lacks flexibility for organizational customization.

#### Recommendations

**Priority: MEDIUM - After core operations**

**Phase 1: Configuration Management**
1. Create `WarehouseSettings` entity:
   - Document numbering formats
   - Default warehouses
   - Auto-approval thresholds
   - Alert configurations
   - Email notification settings

2. Create settings UI in admin panel

**Phase 2: Master Data Management**
3. Implement master data maintenance UIs:
   - Adjustment reasons
   - Transfer types
   - Document types
   - Storage location types

**Phase 3: Approval Workflow Engine**
4. Create flexible approval workflow:
   - Define approval levels by document type
   - Define approval limits by amount/quantity
   - Define approval hierarchy
   - Email notifications
   - Approval delegation

---

### 3.13 รายงานคลังพัสดุขั้นสูง (Advanced Warehouse Reports)

#### Status: ❌ **Not Implemented (5%)**

#### ✅ Implemented Features (Data Available, Reports Not Formatted)

**3.13.1 Stock Card and Movement Reports**
- ✅ Data available via `InventoryInquiryController`
- ❌ No formatted report output

**3.13.2 Balance Reports**
- ✅ Data available via inventory inquiry APIs
- ❌ No formatted reports

**3.13.3-3.13.7 All Other Reports**
- ✅ Raw data exists in database
- ❌ No report generation or formatting

#### ❌ Missing Reports

**All required reports missing:**

**3.13.1 Stock Card และ Movement** (6 reports)
- Stock card report
- Stock card detail and summary
- Stock transaction detail
- Inventory movement report
- Transaction change tracking

**3.13.2 สินค้าคงเหลือ** (4 reports)
- Current stock report
- Stock at specific date
- Monthly stock report
- Stock by warehouse/location

**3.13.3 การรับและจ่าย** (8 reports)
- Stock receive by vendor
- Consignment receipt
- Receipt report / Transfer report
- Return to warehouse report
- Transfer below min level
- Stock below min level by location
- Issue report
- Issue by department

**3.13.4 การสั่งซื้อ** (3 reports)
- Purchase order report
- Purchase order below min level
- Items requiring replenishment

**3.13.5 สินค้าพิเศษ** (4 reports)
- Items expiring within 7 months
- New items report
- Drug/item master change approval form
- Slow-moving/non-moving items

**3.13.6 การจำหน่ายและราคา** (4 reports)
- Sales by item
- Sales by stock take group
- Price list (multiple price types)
- Central drug price report

**3.13.7 รายงานอื่นๆ** (10+ reports)
- Adjustment report
- Ward/department reserve stock
- Weekly issue by ward/department
- Item master changes report
- Barcode/QR code labels
- Stock checklist
- Count tag sheets
- Receipt inspection report
- Goods receipt report

**Total Missing Reports: ~40+ reports**

#### Gap Impact: **HIGH**

While operational processes can function, **management, compliance, and decision-making** are severely limited without reports.

#### Recommendations

**Priority: HIGH - Implement progressively**

**Prioritization Strategy:**

**Tier 1: Essential Daily Operations (Implement First)**
1. Stock balance report (current)
2. Stock card report
3. Goods receipt report
4. Stock issue report
5. Low stock alert report
6. Near-expiry report (7 months)

**Tier 2: Management Reports (Next)**
7. Stock movement summary
8. Stock value report
9. Receipt by vendor
10. Issue by department
11. Monthly stock report
12. Stock at date report

**Tier 3: Compliance and Audit (Then)**
13. Receipt inspection report
14. Adjustment report with reasons
15. Cycle count results
16. Item master change log
17. Transaction audit trail

**Tier 4: Analytics (Finally)**
18. ABC analysis
19. Slow-moving items
20. Stock turnover report
21. Demand forecasting
22. Price comparison

**Implementation Approach:**

**Option A: Reporting Framework**
- Use report designer (Crystal Reports, SSRS, Telerik)
- Create report templates
- Add report generation API endpoints
- Report viewer in frontend

**Option B: Custom Report Builder**
- Build custom report generator with PDF library (QuestPDF, iText)
- More flexible but more development work
- Better for web-based customization

**Option C: Excel Export**
- Quick solution: Export raw data to Excel
- Let users format/pivot
- Lower quality but fast to implement

**Recommended: Option A or B** depending on budget and long-term needs

---

## Summary Gap Analysis Table

| Module | Priority | Status | Implementation % | Critical Gaps |
|--------|----------|--------|------------------|---------------|
| 3.1 General Warehouse | ⚠️ Medium | Partial | 60% | Alerts, return flows |
| 3.2 Internal Requisition | 🔴 HIGH | None | 0% | Entire module missing |
| 3.3 Stock Issue/Dispense | 🔴 HIGH | None | 10% | Issue documents, approval |
| 3.4 Sub-Warehouse Receipt | 🟡 Medium | None | 5% | Receipt confirmation workflow |
| 3.5 Inter-Warehouse Transfer | 🟢 Low | Partial | 70% | Creation UI, document types |
| 3.6 Stock Adjustment | 🔴 HIGH | None | 10% | Adjustment documents, reasons, UI |
| 3.7 Cycle Counting | 🟢 Low | Full | 95% | Minor report enhancements |
| 3.8 Data Management & Reports | 🟡 Medium | Partial | 40% | Print forms, operational reports |
| 3.9 Pharmacy Warehouse | 🔴 HIGH* | Partial | 30% | Pharmacy workflows, pricing, HIS integration |
| 3.10 Advanced Features | 🟢 Low | Partial | 65% | ASN (nice-to-have) |
| 3.11 Budget & Accounting | 🟡 Medium | Partial | 40% | GL integration, budget tracking |
| 3.12 Configuration Management | 🟡 Medium | Partial | 50% | Approval workflows, settings UI |
| 3.13 Advanced Reports | 🔴 HIGH | None | 5% | 40+ reports missing |

**Legend:**
- 🔴 HIGH Priority: Critical for operations
- 🟡 MEDIUM Priority: Important but can work around
- 🟢 LOW Priority: Enhancement/optimization
- *Depends on context (HIGH for hospitals)

---

## Implementation Roadmap Recommendation

### Phase 1: Core Operations (3-4 months)
**Goal: Enable complete inbound-outbound workflow**

1. **Internal Requisition Module** (3 weeks)
   - Entity design, API, frontend
   - Approval workflow
   - Integration with transfer orders

2. **Stock Issue/Dispense Module** (2 weeks)
   - Issue document entity
   - Issue approval and posting
   - UI implementation

3. **Stock Adjustment Module** (2 weeks)
   - Adjustment document entity
   - Reason codes master data
   - UI implementation

4. **Sub-Warehouse Receipt Confirmation** (2 weeks)
   - Receipt note entity
   - Discrepancy handling
   - UI implementation

5. **Tier 1 Essential Reports** (3 weeks)
   - Stock balance, stock card
   - Receipt, issue, low stock reports

**Total: ~12 weeks**

---

### Phase 2: Compliance & Reporting (2-3 months)
**Goal: Management visibility and compliance**

1. **Operational Reports (Tier 2)** (4 weeks)
   - Movement, value, vendor, department reports

2. **Document Printing** (2 weeks)
   - Print templates for all documents
   - Barcode/QR code labels

3. **Alert System** (2 weeks)
   - Low stock alerts
   - Expiry alerts
   - Email notifications

4. **Approval Workflow Engine** (2 weeks)
   - Configurable approval rules
   - Delegation

**Total: ~10 weeks**

---

### Phase 3: Pharmacy Enhancements (2-3 months)
**Goal: Full pharmacy compliance** *(if hospital system)*

1. **Pharmacy Master Data Enhancement** (3 weeks)
   - Medical item fields
   - Pricing schemes
   - Drug classifications

2. **Pharmacy Workflows** (3 weeks)
   - Pharmacy requisition
   - Controlled substance tracking

3. **Pharmacy Reports** (3 weeks)
   - All pharmacy-specific reports

4. **HIS Integration** (3 weeks)
   - Prescription interface
   - Dispensing records

**Total: ~12 weeks**

---

### Phase 4: Advanced Features (2 months)
**Goal: Optimization and analytics**

1. **Budget & Accounting Integration** (3 weeks)
2. **ASN Implementation** (2 weeks)
3. **Tier 3-4 Reports & Analytics** (3 weeks)
4. **Configuration Management UI** (2 weeks)

**Total: ~10 weeks**

---

## Total Effort Estimate

| Phase | Duration | Priority |
|-------|----------|----------|
| Phase 1: Core Operations | 12 weeks | CRITICAL |
| Phase 2: Compliance & Reporting | 10 weeks | HIGH |
| Phase 3: Pharmacy | 12 weeks | HIGH (if hospital) |
| Phase 4: Advanced | 10 weeks | MEDIUM |

**Total: 44 weeks (~10-11 months)** for complete implementation

**Critical path (Phases 1-2): 22 weeks (~5-6 months)** for operational system

---

## Conclusion

The PIAM warehouse management system has a **solid foundation** with:
- ✅ Excellent inventory tracking infrastructure
- ✅ Well-implemented goods receipt workflow
- ✅ Strong cycle counting capability
- ✅ Good location and lot management

However, to meet the full requirements in `doc/warehouse.txt`, the following are **critical gaps**:

### Must Implement (Phase 1):
1. **Internal Requisition** - Core workflow missing
2. **Stock Issue** - Outbound process incomplete
3. **Stock Adjustment** - Cannot maintain accuracy
4. **Essential Reports** - Management blind without these

### Should Implement (Phase 2):
5. **Full Reporting Suite** - Compliance and decision support
6. **Sub-Warehouse Receipts** - Accountability and audit trail
7. **Alert System** - Proactive stock management

### Consider Implementing (Phase 3-4):
8. **Pharmacy Enhancements** - If medical/hospital context
9. **Budget/Accounting Integration** - If standalone system
10. **ASN and Advanced Features** - If high-volume operations

The current implementation is approximately **50% complete** against the full requirements specification.

---

**End of Gap Analysis Document**