docs-piam/references/warehouse-gap-analysis.md

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