[update] - init project
This commit is contained in:
16
drug_data.json
Normal file
16
drug_data.json
Normal file
@@ -0,0 +1,16 @@
|
|||||||
|
{
|
||||||
|
"source": "https://dmsic.moph.go.th/index/drugsearch/3",
|
||||||
|
"keyword": "A",
|
||||||
|
"drug": {
|
||||||
|
"name": "Abacavir sulfate tab 300 mg",
|
||||||
|
"ขนาดบรรจุ": "1 เม็ด",
|
||||||
|
"ปริมาณ": "",
|
||||||
|
"ราคา_รวม_VAT": 12.67,
|
||||||
|
"หมายเหตุ": "33. กลุ่มยาที่มีปัญหาจัดซื้อ"
|
||||||
|
},
|
||||||
|
"metadata": {
|
||||||
|
"source_organization": "ศูนย์ข้อมูลสาขาสารสนเทศยาเพื่อนโยบาย กระทรวงสาธารณสุข",
|
||||||
|
"announcement_date": "30 สิงหาคม 2567",
|
||||||
|
"extracted_date": "2025-11-07"
|
||||||
|
}
|
||||||
|
}
|
||||||
517
pr-after-approval-guide.md
Normal file
517
pr-after-approval-guide.md
Normal file
@@ -0,0 +1,517 @@
|
|||||||
|
# What Happens After Purchase Requisition Approval
|
||||||
|
|
||||||
|
## Document Information
|
||||||
|
- **Document Type**: Process Guide
|
||||||
|
- **Audience**: All Procurement Users
|
||||||
|
- **Last Updated**: 2025-10-30
|
||||||
|
- **Version**: 1.0
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
Understanding what happens after a Purchase Requisition (PR) is approved is essential for planning your procurement activities. This document explains the approval consequences, status transitions, and document immutability rules.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [Immediate Effects of Approval](#immediate-effects-of-approval)
|
||||||
|
2. [Status Transitions After Approval](#status-transitions-after-approval)
|
||||||
|
3. [Document Immutability Explained](#document-immutability-explained)
|
||||||
|
4. [Budget Impact](#budget-impact)
|
||||||
|
5. [Next Steps in Procurement](#next-steps-in-procurement)
|
||||||
|
6. [Audit Trail](#audit-trail)
|
||||||
|
7. [Frequently Asked Questions](#frequently-asked-questions)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Immediate Effects of Approval
|
||||||
|
|
||||||
|
When an approver clicks "Approve" on a Purchase Requisition, several things happen instantly:
|
||||||
|
|
||||||
|
### 1. Status Change
|
||||||
|
```
|
||||||
|
Pending Approval → Approved
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Document Lock
|
||||||
|
- ❌ **All editing is disabled**
|
||||||
|
- ❌ Cannot modify any field
|
||||||
|
- ❌ Cannot add or remove line items
|
||||||
|
- ❌ Cannot change quantities or prices
|
||||||
|
- ❌ Cannot update budget information
|
||||||
|
|
||||||
|
### 3. Approval Information Recorded
|
||||||
|
The system captures:
|
||||||
|
- **Approved By**: Name of the approver
|
||||||
|
- **Approved At**: Date and time of approval (UTC)
|
||||||
|
- **Approval Remarks**: Any comments from approver
|
||||||
|
- **User Information**: IP address and system details
|
||||||
|
|
||||||
|
### 4. Budget Commitment
|
||||||
|
- Budget is marked as committed
|
||||||
|
- Amount is reserved against budget code
|
||||||
|
- Available budget is reduced
|
||||||
|
- Budget tracking is updated
|
||||||
|
|
||||||
|
### 5. Notifications Sent
|
||||||
|
- Requester receives approval notification
|
||||||
|
- Procurement team is notified
|
||||||
|
- Finance team may receive notification
|
||||||
|
- Next step assignees are alerted
|
||||||
|
|
||||||
|
### 6. Audit Log Entry
|
||||||
|
- Approval action is logged
|
||||||
|
- Full audit trail is maintained
|
||||||
|
- Timestamps are recorded
|
||||||
|
- User actions are tracked
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Status Transitions After Approval
|
||||||
|
|
||||||
|
Once approved, a PR can move through these statuses:
|
||||||
|
|
||||||
|
### Approved → Converted to RFQ
|
||||||
|
|
||||||
|
**When**: PR is converted to Request for Quotation
|
||||||
|
|
||||||
|
**Process**:
|
||||||
|
1. Procurement team reviews approved PR
|
||||||
|
2. Decision made to obtain quotations
|
||||||
|
3. RFQ is created from PR
|
||||||
|
4. PR status updates to "Converted to RFQ"
|
||||||
|
|
||||||
|
**Impact**:
|
||||||
|
- PR remains permanently locked
|
||||||
|
- RFQ process begins
|
||||||
|
- Suppliers will be invited to quote
|
||||||
|
- Original PR serves as audit reference
|
||||||
|
|
||||||
|
### Approved → Converted to Purchase Order
|
||||||
|
|
||||||
|
**When**: PR is directly converted to PO (without RFQ)
|
||||||
|
|
||||||
|
**Process**:
|
||||||
|
1. Supplier is already known
|
||||||
|
2. Pricing is pre-agreed
|
||||||
|
3. PO is created directly from PR
|
||||||
|
4. PR status updates to "Converted to PO"
|
||||||
|
|
||||||
|
**Common Scenarios**:
|
||||||
|
- Single source supplier
|
||||||
|
- Framework agreement purchases
|
||||||
|
- Emergency procurements
|
||||||
|
- Low-value purchases
|
||||||
|
|
||||||
|
**Impact**:
|
||||||
|
- PR remains permanently locked
|
||||||
|
- PO is issued to supplier
|
||||||
|
- Delivery process begins
|
||||||
|
- Original PR serves as audit reference
|
||||||
|
|
||||||
|
### Any Status → Closed
|
||||||
|
|
||||||
|
**When**: PR is closed for various reasons
|
||||||
|
|
||||||
|
**Reasons for Closing**:
|
||||||
|
- ✅ **Completed**: Full procurement cycle finished
|
||||||
|
- ❌ **Cancelled**: No longer needed
|
||||||
|
- ⏸️ **On Hold**: Temporarily suspended
|
||||||
|
- 🔄 **Superseded**: Replaced by new PR
|
||||||
|
|
||||||
|
**Impact**:
|
||||||
|
- PR is permanently archived
|
||||||
|
- No further actions possible
|
||||||
|
- Audit trail is preserved
|
||||||
|
- Cannot be reopened
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Document Immutability Explained
|
||||||
|
|
||||||
|
### What Is Immutability?
|
||||||
|
|
||||||
|
**Immutability** means a document cannot be changed or modified after a certain point. For Purchase Requisitions, this happens at approval.
|
||||||
|
|
||||||
|
### Why Is It Important?
|
||||||
|
|
||||||
|
#### 1. Financial Control
|
||||||
|
- **Before Approval**: Amount can change
|
||||||
|
- **After Approval**: Amount is fixed
|
||||||
|
- **Reason**: Budget commitment must be accurate
|
||||||
|
|
||||||
|
Example:
|
||||||
|
```
|
||||||
|
PR #12345
|
||||||
|
Draft: $5,000 → Changed to $6,000 ✅ (allowed)
|
||||||
|
Approved: $6,000 → Cannot change to $7,000 ❌ (blocked)
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. Audit Compliance
|
||||||
|
- What was approved must match what was procured
|
||||||
|
- Audit trail must show original approved amounts
|
||||||
|
- No retroactive changes allowed
|
||||||
|
- Complete accountability maintained
|
||||||
|
|
||||||
|
#### 3. Process Integrity
|
||||||
|
- Prevents bypassing approval workflow
|
||||||
|
- Stops unauthorized changes
|
||||||
|
- Maintains approval authority
|
||||||
|
- Ensures proper governance
|
||||||
|
|
||||||
|
#### 4. Legal Protection
|
||||||
|
- Approved document is legal commitment
|
||||||
|
- Serves as contract basis
|
||||||
|
- Protects organization from disputes
|
||||||
|
- Ensures compliance with regulations
|
||||||
|
|
||||||
|
### Which Statuses Are Immutable?
|
||||||
|
|
||||||
|
| Status | Immutable? | Can View? | Can Edit? | Can Approve? |
|
||||||
|
|--------|-----------|-----------|-----------|--------------|
|
||||||
|
| Draft | ❌ No | ✅ Yes | ✅ Yes | ❌ No |
|
||||||
|
| Pending Approval | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes |
|
||||||
|
| Approved | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
|
||||||
|
| Rejected | ❌ No | ✅ Yes | ✅ Yes | ❌ No |
|
||||||
|
| Converted to RFQ | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
|
||||||
|
| Converted to PO | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
|
||||||
|
| Closed | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
|
||||||
|
|
||||||
|
### Visual Indicators of Immutability
|
||||||
|
|
||||||
|
When you view an immutable PR, you'll see:
|
||||||
|
|
||||||
|
#### 1. Lock Icon 🔒
|
||||||
|
```
|
||||||
|
Purchase Requisition #PR-2025-001234 🔒
|
||||||
|
```
|
||||||
|
- Appears in page header
|
||||||
|
- Clearly indicates locked status
|
||||||
|
- Tooltip explains why locked
|
||||||
|
|
||||||
|
#### 2. Document Locked Banner
|
||||||
|
```
|
||||||
|
┌─────────────────────────────────────────────────┐
|
||||||
|
│ ⚠️ This document is locked and cannot be edited │
|
||||||
|
│ Purchase requisitions cannot be modified after │
|
||||||
|
│ approval. Contact your administrator if changes │
|
||||||
|
│ are needed. │
|
||||||
|
└─────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3. View Only Badge
|
||||||
|
```
|
||||||
|
[View Only]
|
||||||
|
```
|
||||||
|
- Appears near action buttons
|
||||||
|
- Replaces edit/save buttons
|
||||||
|
- Clear visual cue
|
||||||
|
|
||||||
|
#### 4. Grayed Out Fields
|
||||||
|
- All input fields are disabled
|
||||||
|
- Text is grayed out
|
||||||
|
- No cursor in fields
|
||||||
|
- Clear visual difference from editable form
|
||||||
|
|
||||||
|
#### 5. No Action Buttons
|
||||||
|
- No "Save Draft" button
|
||||||
|
- No "Submit for Approval" button
|
||||||
|
- Only "Close" or "Back" available
|
||||||
|
- Print/Export may be available
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Budget Impact
|
||||||
|
|
||||||
|
### At Approval Time
|
||||||
|
|
||||||
|
#### Budget Commitment
|
||||||
|
When PR is approved, the budget is committed:
|
||||||
|
|
||||||
|
```
|
||||||
|
Budget Code: OPEX-2025-IT-001
|
||||||
|
Available Budget Before: $50,000
|
||||||
|
PR Amount: $10,000
|
||||||
|
Available Budget After: $40,000
|
||||||
|
Committed Budget: $10,000
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Budget Tracking
|
||||||
|
- Amount is tracked against budget code
|
||||||
|
- Remaining budget is calculated
|
||||||
|
- Future PRs check available budget
|
||||||
|
- Budget reports show commitments
|
||||||
|
|
||||||
|
#### Budget Period
|
||||||
|
- Commitment is for current fiscal period
|
||||||
|
- Crossing fiscal years may require special approval
|
||||||
|
- Budget may roll over or expire based on policy
|
||||||
|
|
||||||
|
### What If Budget Changes?
|
||||||
|
|
||||||
|
#### Scenario: Budget Increased After Approval
|
||||||
|
- Approved PR amount doesn't change
|
||||||
|
- Additional budget available for new PRs
|
||||||
|
- Original PR remains as approved
|
||||||
|
|
||||||
|
#### Scenario: Budget Cut After Approval
|
||||||
|
- Approved PRs are honored
|
||||||
|
- May affect future PRs
|
||||||
|
- Finance may review commitments
|
||||||
|
- Special approval may be needed
|
||||||
|
|
||||||
|
#### Scenario: Budget Reallocated
|
||||||
|
- Finance handles budget transfers
|
||||||
|
- Approved PRs follow original budget
|
||||||
|
- New PRs use new budget allocation
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Next Steps in Procurement
|
||||||
|
|
||||||
|
### Immediately After Approval
|
||||||
|
|
||||||
|
#### 1. Procurement Review (Day 1-2)
|
||||||
|
- Procurement team reviews approved PR
|
||||||
|
- Verifies item specifications
|
||||||
|
- Confirms supplier availability
|
||||||
|
- Plans procurement method
|
||||||
|
|
||||||
|
#### 2. Sourcing Decision (Day 2-3)
|
||||||
|
Procurement decides:
|
||||||
|
- **Option A**: Create RFQ (multiple suppliers)
|
||||||
|
- **Option B**: Create PO directly (single supplier)
|
||||||
|
- **Option C**: Use framework agreement
|
||||||
|
|
||||||
|
#### 3. Document Creation (Day 3-5)
|
||||||
|
- RFQ or PO is created from PR
|
||||||
|
- PR status updates to "Converted"
|
||||||
|
- Procurement process continues
|
||||||
|
- PR serves as reference
|
||||||
|
|
||||||
|
### Timeline Expectations
|
||||||
|
|
||||||
|
#### Small Purchases (<$10,000)
|
||||||
|
```
|
||||||
|
Approval → PO Creation: 1-3 business days
|
||||||
|
PO Creation → Delivery: 5-10 business days
|
||||||
|
Total Time: 6-13 business days
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Medium Purchases ($10,000-$50,000)
|
||||||
|
```
|
||||||
|
Approval → RFQ Creation: 2-3 business days
|
||||||
|
RFQ Process: 7-14 business days
|
||||||
|
PO Creation → Delivery: 10-20 business days
|
||||||
|
Total Time: 19-37 business days
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Large Purchases (>$50,000)
|
||||||
|
```
|
||||||
|
Approval → RFQ Creation: 3-5 business days
|
||||||
|
RFQ Process: 14-30 business days
|
||||||
|
Evaluation & Award: 5-10 business days
|
||||||
|
PO Creation → Delivery: 20-45 business days
|
||||||
|
Total Time: 42-90 business days
|
||||||
|
```
|
||||||
|
|
||||||
|
*Note: Timelines vary by organization and procurement policy*
|
||||||
|
|
||||||
|
### Tracking Your PR
|
||||||
|
|
||||||
|
#### Status Monitoring
|
||||||
|
1. Navigate to **Procurement → Purchase Requisitions**
|
||||||
|
2. Find your PR by number
|
||||||
|
3. Check current status
|
||||||
|
4. View status history
|
||||||
|
|
||||||
|
#### Related Documents
|
||||||
|
Once converted, you can see:
|
||||||
|
- Link to RFQ (if created)
|
||||||
|
- Link to PO (if created)
|
||||||
|
- Related contracts
|
||||||
|
- Delivery documents
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Audit Trail
|
||||||
|
|
||||||
|
### What Is Recorded?
|
||||||
|
|
||||||
|
Every action on a PR is tracked:
|
||||||
|
|
||||||
|
#### 1. Creation
|
||||||
|
- Created by (user name)
|
||||||
|
- Created at (date/time)
|
||||||
|
- Initial values
|
||||||
|
|
||||||
|
#### 2. Modifications (Draft Stage)
|
||||||
|
- Changed by (user name)
|
||||||
|
- Changed at (date/time)
|
||||||
|
- What was changed (before/after values)
|
||||||
|
|
||||||
|
#### 3. Submission
|
||||||
|
- Submitted by
|
||||||
|
- Submitted at
|
||||||
|
- Status transition: Draft → Pending Approval
|
||||||
|
|
||||||
|
#### 4. Approval/Rejection
|
||||||
|
- Approved/Rejected by
|
||||||
|
- Approved/Rejected at
|
||||||
|
- Approval remarks
|
||||||
|
- User's IP address
|
||||||
|
- System information
|
||||||
|
|
||||||
|
#### 5. Modification Attempts (After Approval)
|
||||||
|
- Attempted by (user name)
|
||||||
|
- Attempted at (date/time)
|
||||||
|
- What user tried to change
|
||||||
|
- Why it was blocked
|
||||||
|
- IP address
|
||||||
|
- User agent
|
||||||
|
|
||||||
|
#### 6. Conversions
|
||||||
|
- Converted by
|
||||||
|
- Converted at
|
||||||
|
- Converted to (RFQ/PO)
|
||||||
|
- Reference numbers
|
||||||
|
|
||||||
|
### Viewing Audit Logs
|
||||||
|
|
||||||
|
#### For Regular Users:
|
||||||
|
- View approval history on PR detail page
|
||||||
|
- See who approved and when
|
||||||
|
- View approval remarks
|
||||||
|
|
||||||
|
#### For Administrators:
|
||||||
|
- Access full audit logs
|
||||||
|
- View all modification attempts
|
||||||
|
- See detailed change history
|
||||||
|
- Export audit reports
|
||||||
|
|
||||||
|
### Audit Log Retention
|
||||||
|
- **Standard Retention**: 7 years
|
||||||
|
- **Legal Requirements**: Per local regulations
|
||||||
|
- **Access Controls**: Restricted to authorized personnel
|
||||||
|
- **Backup**: Included in system backups
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Frequently Asked Questions
|
||||||
|
|
||||||
|
### General Questions
|
||||||
|
|
||||||
|
**Q: Can I edit my PR after approval?**
|
||||||
|
A: No. Once approved, PRs are permanently locked to maintain audit integrity and financial control.
|
||||||
|
|
||||||
|
**Q: What if I made a mistake in the PR?**
|
||||||
|
A: Contact your supervisor or procurement manager. Depending on the stage:
|
||||||
|
- Not yet converted: May need to create new PR
|
||||||
|
- Already converted: Changes must be in RFQ/PO
|
||||||
|
|
||||||
|
**Q: How long does approval take?**
|
||||||
|
A: Varies by organization. Typically 1-3 business days for standard PRs. Urgent PRs may be expedited.
|
||||||
|
|
||||||
|
**Q: Can I cancel an approved PR?**
|
||||||
|
A: Not directly. Contact procurement team. They can close it if not yet converted.
|
||||||
|
|
||||||
|
### Budget Questions
|
||||||
|
|
||||||
|
**Q: Does approval mean budget is spent?**
|
||||||
|
A: No. Budget is "committed" (reserved) but not spent until goods/services are received.
|
||||||
|
|
||||||
|
**Q: What happens if budget is unavailable?**
|
||||||
|
A: PR shouldn't be approved without budget. If approved incorrectly, finance will review.
|
||||||
|
|
||||||
|
**Q: Can I use the same budget for multiple PRs?**
|
||||||
|
A: Yes, as long as total doesn't exceed available budget. Each PR commits its portion.
|
||||||
|
|
||||||
|
### Process Questions
|
||||||
|
|
||||||
|
**Q: When will I receive my items?**
|
||||||
|
A: After approval:
|
||||||
|
1. PR converts to RFQ/PO (1-5 days)
|
||||||
|
2. Supplier processes order (varies)
|
||||||
|
3. Delivery (depends on items)
|
||||||
|
Total: 2-12 weeks typically
|
||||||
|
|
||||||
|
**Q: Can I track delivery?**
|
||||||
|
A: Yes, once converted to PO. PO will have tracking information.
|
||||||
|
|
||||||
|
**Q: What if supplier delays delivery?**
|
||||||
|
A: Contact procurement team. They manage supplier relationships and delivery schedules.
|
||||||
|
|
||||||
|
### Technical Questions
|
||||||
|
|
||||||
|
**Q: Why can't I click Save button?**
|
||||||
|
A: If PR is approved, there's no Save button. Document is locked. You can only view.
|
||||||
|
|
||||||
|
**Q: System shows "Document Locked" error**
|
||||||
|
A: This is normal for approved PRs. It's a security feature to prevent unauthorized changes.
|
||||||
|
|
||||||
|
**Q: Can admin override the lock?**
|
||||||
|
A: Generally no. Even administrators must follow audit and compliance rules. Special amendment procedures may exist.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Important Reminders
|
||||||
|
|
||||||
|
### Before Submitting for Approval
|
||||||
|
|
||||||
|
✅ **Double-check everything** - You won't be able to edit after approval
|
||||||
|
|
||||||
|
✅ **Verify quantities** - Make sure amounts are correct
|
||||||
|
|
||||||
|
✅ **Confirm budget code** - Ensure correct budget is charged
|
||||||
|
|
||||||
|
✅ **Review pricing** - Verify prices are reasonable
|
||||||
|
|
||||||
|
✅ **Check delivery date** - Ensure timeline is realistic
|
||||||
|
|
||||||
|
### After Approval
|
||||||
|
|
||||||
|
📌 **Save your PR number** - Keep for tracking and reference
|
||||||
|
|
||||||
|
📌 **Monitor status** - Check periodically for updates
|
||||||
|
|
||||||
|
📌 **Coordinate with procurement** - They'll handle next steps
|
||||||
|
|
||||||
|
📌 **Plan for delivery** - Prepare for goods arrival
|
||||||
|
|
||||||
|
📌 **Keep documentation** - Save approval emails and documents
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Need Help?
|
||||||
|
|
||||||
|
### Quick Reference
|
||||||
|
|
||||||
|
- **View PR Status**: Procurement → Purchase Requisitions → Find PR
|
||||||
|
- **Check Budget**: Budget Reports or Finance Department
|
||||||
|
- **Track Delivery**: PO tracking once converted
|
||||||
|
- **Approval Issues**: Contact your supervisor
|
||||||
|
- **Technical Issues**: Contact IT Support
|
||||||
|
|
||||||
|
### Contact Information
|
||||||
|
|
||||||
|
- **Procurement Team**: [Your org contact]
|
||||||
|
- **Finance Department**: [Your org contact]
|
||||||
|
- **IT Support**: [Your org contact]
|
||||||
|
- **Supervisor**: [Department specific]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Related Documentation
|
||||||
|
|
||||||
|
- **User Guide**: Complete guide to creating and approving PRs
|
||||||
|
- **FAQ Document**: Answers to common questions
|
||||||
|
- **System Administrator Guide**: Technical implementation details
|
||||||
|
- **Training Materials**: Available from IT Department
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Document End**
|
||||||
|
|
||||||
|
*This document explains the post-approval process. For complete PR lifecycle information, see the User Guide.*
|
||||||
1078
pr-approval-admin-guide.md
Normal file
1078
pr-approval-admin-guide.md
Normal file
File diff suppressed because it is too large
Load Diff
747
pr-approval-faq.md
Normal file
747
pr-approval-faq.md
Normal file
@@ -0,0 +1,747 @@
|
|||||||
|
# Purchase Requisition Approval - FAQ
|
||||||
|
|
||||||
|
## Document Information
|
||||||
|
- **Document Type**: Frequently Asked Questions
|
||||||
|
- **Last Updated**: 2025-10-30
|
||||||
|
- **Version**: 1.0
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Quick Navigation
|
||||||
|
|
||||||
|
- [Creating PRs](#creating-prs)
|
||||||
|
- [Editing and Saving](#editing-and-saving)
|
||||||
|
- [Submitting for Approval](#submitting-for-approval)
|
||||||
|
- [Approval Process](#approval-process)
|
||||||
|
- [After Approval](#after-approval)
|
||||||
|
- [Document Locking](#document-locking)
|
||||||
|
- [Errors and Issues](#errors-and-issues)
|
||||||
|
- [Budget and Finance](#budget-and-finance)
|
||||||
|
- [Technical Issues](#technical-issues)
|
||||||
|
- [Process and Policy](#process-and-policy)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Creating PRs
|
||||||
|
|
||||||
|
### Can I create a PR without knowing the exact price?
|
||||||
|
|
||||||
|
**Yes.** You can enter estimated prices when creating a PR. The system accepts approximate amounts for budgeting purposes. Actual prices will be determined during the RFQ or PO process.
|
||||||
|
|
||||||
|
**Best Practice**: Use recent market prices or previous purchase prices as estimates.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Do I need approval to create a PR?
|
||||||
|
|
||||||
|
**No.** Anyone with system access can create a PR in Draft status. Approval is only required when you submit the PR. However, your organization may have policies about who can request certain items.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I save a partially completed PR?
|
||||||
|
|
||||||
|
**Yes.** Click "Save Draft" at any time. You can return later to complete it. Draft PRs remain editable indefinitely until submitted.
|
||||||
|
|
||||||
|
**Tip**: Save frequently to avoid losing your work.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### How long can I keep a PR in Draft status?
|
||||||
|
|
||||||
|
**Indefinitely**, but:
|
||||||
|
- Budget codes may change
|
||||||
|
- Prices may change
|
||||||
|
- Items may become unavailable
|
||||||
|
- Your organization may have cleanup policies
|
||||||
|
|
||||||
|
**Recommendation**: Complete and submit within 1-2 weeks of starting.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I copy an existing PR?
|
||||||
|
|
||||||
|
**It depends** on your system configuration. Some systems allow "Copy PR" functionality. Check with your IT team. Otherwise, you can manually reference an old PR when creating a new one.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I delete a Draft PR?
|
||||||
|
|
||||||
|
**Yes.** Draft PRs can be deleted if no longer needed. Once submitted or approved, deletion is typically not allowed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Editing and Saving
|
||||||
|
|
||||||
|
### Why can't I edit my PR?
|
||||||
|
|
||||||
|
**Check these**:
|
||||||
|
1. **Status**: Only Draft PRs are editable
|
||||||
|
2. **Page**: You must be on the edit page (URL contains `/edit`)
|
||||||
|
3. **Permissions**: You need edit permissions
|
||||||
|
4. **Lock status**: See lock icon or "View Only" badge
|
||||||
|
|
||||||
|
**Solution**: Check PR status. If not Draft, see [Why is my PR locked?](#why-is-my-pr-locked)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### I'm on the edit page but fields are grayed out. Why?
|
||||||
|
|
||||||
|
**Most likely**: PR status is not Draft
|
||||||
|
- Pending Approval: In workflow, cannot edit
|
||||||
|
- Approved: Locked permanently
|
||||||
|
- Converted: Already processed
|
||||||
|
|
||||||
|
**Visual clues**:
|
||||||
|
- Lock icon 🔒 in header
|
||||||
|
- "Document Locked" banner
|
||||||
|
- "View Only" badge
|
||||||
|
- No Save/Submit buttons
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I edit someone else's Draft PR?
|
||||||
|
|
||||||
|
**It depends** on:
|
||||||
|
- Your permissions in the system
|
||||||
|
- Your organization's policies
|
||||||
|
- Whether you're a supervisor
|
||||||
|
|
||||||
|
**Generally**: People should edit their own PRs unless there's a specific reason and authorization.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Does saving a Draft send notifications?
|
||||||
|
|
||||||
|
**No.** Saving a Draft does not trigger notifications. Only submission sends notifications to approvers.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What happens if I close the browser without saving?
|
||||||
|
|
||||||
|
**Your changes are lost** unless:
|
||||||
|
- The system has auto-save (check with IT)
|
||||||
|
- You clicked "Save Draft" before closing
|
||||||
|
|
||||||
|
**Best Practice**: Click "Save Draft" frequently, especially before breaks or end of day.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Submitting for Approval
|
||||||
|
|
||||||
|
### Can I edit after submitting?
|
||||||
|
|
||||||
|
**No.** Once submitted:
|
||||||
|
- Status changes to "Pending Approval"
|
||||||
|
- All fields become locked
|
||||||
|
- You cannot make changes
|
||||||
|
|
||||||
|
**If you need changes**: Ask approver to reject the PR so it returns to Draft status.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What if I submitted by mistake?
|
||||||
|
|
||||||
|
**Act quickly**:
|
||||||
|
1. Contact the approver immediately
|
||||||
|
2. Explain it was submitted prematurely
|
||||||
|
3. Ask them to reject it with a note
|
||||||
|
4. Make corrections when it returns to Draft
|
||||||
|
5. Resubmit when ready
|
||||||
|
|
||||||
|
**Prevention**: Always review carefully before clicking "Submit for Approval"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I cancel a submission?
|
||||||
|
|
||||||
|
**No.** Once submitted, you cannot cancel. The approver must either:
|
||||||
|
- Approve it
|
||||||
|
- Reject it (returns to Draft)
|
||||||
|
|
||||||
|
**Workaround**: Contact approver to request rejection.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Who receives notifications when I submit?
|
||||||
|
|
||||||
|
**Typically**:
|
||||||
|
- Your direct supervisor
|
||||||
|
- Department head
|
||||||
|
- Finance controller (for budget approval)
|
||||||
|
- Procurement team (for awareness)
|
||||||
|
|
||||||
|
**Varies by**:
|
||||||
|
- PR amount
|
||||||
|
- Budget code
|
||||||
|
- Item type
|
||||||
|
- Organization's workflow configuration
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### How long should I wait for approval?
|
||||||
|
|
||||||
|
**Typical timeframes**:
|
||||||
|
- Standard PRs: 1-3 business days
|
||||||
|
- Urgent PRs: Same day to 1 day
|
||||||
|
- High-value PRs: 3-5 business days
|
||||||
|
- Complex PRs: Up to 1 week
|
||||||
|
|
||||||
|
**If delayed**: Contact approver or send a reminder after reasonable wait time.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I expedite approval?
|
||||||
|
|
||||||
|
**For urgent needs**:
|
||||||
|
1. Mark PR as high priority
|
||||||
|
2. Add urgency explanation in remarks
|
||||||
|
3. Contact approver directly
|
||||||
|
4. Provide justification for urgency
|
||||||
|
|
||||||
|
**Note**: Abuse of "urgent" flags may reduce credibility.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Approval Process
|
||||||
|
|
||||||
|
### Who can approve my PR?
|
||||||
|
|
||||||
|
**Depends on**:
|
||||||
|
- PR amount
|
||||||
|
- Budget code
|
||||||
|
- Department
|
||||||
|
- Organization hierarchy
|
||||||
|
|
||||||
|
**Common approvers**:
|
||||||
|
- Department heads (up to certain amount)
|
||||||
|
- Finance controllers (budget approval)
|
||||||
|
- Procurement managers (technical approval)
|
||||||
|
- Senior management (high-value items)
|
||||||
|
|
||||||
|
**Check with**: Your supervisor or finance department for specific thresholds.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Do I need multiple approvals?
|
||||||
|
|
||||||
|
**It varies** based on:
|
||||||
|
- PR amount (higher amounts need more approvals)
|
||||||
|
- Item type (capital equipment needs special approval)
|
||||||
|
- Budget source (restricted funds need finance approval)
|
||||||
|
|
||||||
|
**Example workflow**:
|
||||||
|
```
|
||||||
|
< $5,000: Department head only
|
||||||
|
$5,000-$25,000: Department head + Finance controller
|
||||||
|
> $25,000: Department head + Finance + Procurement manager
|
||||||
|
```
|
||||||
|
|
||||||
|
*Your organization may have different thresholds*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I see who approved my PR?
|
||||||
|
|
||||||
|
**Yes.** On the PR detail page, you can see:
|
||||||
|
- Approver name
|
||||||
|
- Approval date/time
|
||||||
|
- Approval remarks
|
||||||
|
- Full approval history
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can an approval be revoked?
|
||||||
|
|
||||||
|
**Generally no** once approved, due to:
|
||||||
|
- Budget commitment
|
||||||
|
- Audit requirements
|
||||||
|
- Process integrity
|
||||||
|
|
||||||
|
**Exception**: Some systems allow revocation if:
|
||||||
|
- Not yet converted to RFQ/PO
|
||||||
|
- Senior management authorization
|
||||||
|
- Documented justification
|
||||||
|
- Full audit trail maintained
|
||||||
|
|
||||||
|
**Check with**: Your finance or procurement department.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What if approver rejects my PR?
|
||||||
|
|
||||||
|
**What happens**:
|
||||||
|
1. PR status returns to "Draft"
|
||||||
|
2. You receive rejection notification
|
||||||
|
3. Rejection remarks explain what needs fixing
|
||||||
|
4. You can now edit the PR again
|
||||||
|
|
||||||
|
**Next steps**:
|
||||||
|
1. Review rejection remarks carefully
|
||||||
|
2. Make requested corrections
|
||||||
|
3. Address all concerns
|
||||||
|
4. Resubmit for approval
|
||||||
|
|
||||||
|
**Tip**: Contact approver if rejection reason is unclear.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## After Approval
|
||||||
|
|
||||||
|
### What happens immediately after approval?
|
||||||
|
|
||||||
|
**Automatic actions**:
|
||||||
|
1. Status changes to "Approved"
|
||||||
|
2. Budget is committed
|
||||||
|
3. Document becomes locked
|
||||||
|
4. Notifications sent to procurement
|
||||||
|
5. Audit log updated
|
||||||
|
6. Approval information recorded
|
||||||
|
|
||||||
|
**You can**: View PR and track its progress
|
||||||
|
|
||||||
|
**You cannot**: Edit any information
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### How long until I receive my items?
|
||||||
|
|
||||||
|
**Timeline varies**:
|
||||||
|
1. **PR to RFQ/PO**: 1-5 business days
|
||||||
|
2. **Supplier processing**: 1-4 weeks
|
||||||
|
3. **Shipping**: 1-8 weeks
|
||||||
|
4. **Receiving**: 1-3 days
|
||||||
|
|
||||||
|
**Total**: 2-12 weeks typical
|
||||||
|
- Small items: 2-4 weeks
|
||||||
|
- Standard items: 4-8 weeks
|
||||||
|
- Special orders: 8-12 weeks
|
||||||
|
- International: 12+ weeks
|
||||||
|
|
||||||
|
**Track**: Via PO number once created
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I change delivery address after approval?
|
||||||
|
|
||||||
|
**It depends**:
|
||||||
|
- Not yet converted: Contact procurement, may be possible
|
||||||
|
- Already converted to PO: Must change in PO, not PR
|
||||||
|
- Already shipped: May not be possible
|
||||||
|
|
||||||
|
**Best practice**: Verify delivery address before submitting PR.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I cancel items after approval?
|
||||||
|
|
||||||
|
**Process**:
|
||||||
|
1. Contact procurement team immediately
|
||||||
|
2. Explain why cancellation is needed
|
||||||
|
3. If not yet converted: May be possible to close PR
|
||||||
|
4. If converted to PO: Must cancel PO (complex process)
|
||||||
|
|
||||||
|
**Consequences**:
|
||||||
|
- Budget may remain committed temporarily
|
||||||
|
- Supplier may charge cancellation fees
|
||||||
|
- May affect future procurement
|
||||||
|
|
||||||
|
**Prevention**: Verify requirements before submitting.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Why hasn't my approved PR converted to PO?
|
||||||
|
|
||||||
|
**Common reasons**:
|
||||||
|
1. **Procurement queue**: Waiting for processing
|
||||||
|
2. **Supplier verification**: Checking supplier availability
|
||||||
|
3. **Budget confirmation**: Final budget check
|
||||||
|
4. **Specifications**: Clarifying item details
|
||||||
|
5. **Workload**: High volume period
|
||||||
|
|
||||||
|
**Typical wait**: 1-5 business days
|
||||||
|
|
||||||
|
**Action**: Contact procurement if waiting > 5 days.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Document Locking
|
||||||
|
|
||||||
|
### Why is my PR locked?
|
||||||
|
|
||||||
|
**PRs are locked when status is**:
|
||||||
|
- ✅ Pending Approval: In workflow
|
||||||
|
- ✅ Approved: Budget committed
|
||||||
|
- ✅ Converted to RFQ: Already converted
|
||||||
|
- ✅ Converted to PO: Already converted
|
||||||
|
- ✅ Closed: Process complete
|
||||||
|
|
||||||
|
**Only Draft status allows editing**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I unlock an approved PR?
|
||||||
|
|
||||||
|
**No.** Immutability is by design:
|
||||||
|
- Maintains audit trail
|
||||||
|
- Protects budget integrity
|
||||||
|
- Ensures compliance
|
||||||
|
- Prevents unauthorized changes
|
||||||
|
|
||||||
|
**Alternative**: Create new PR if significant changes needed (consult supervisor).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What if I made a critical error?
|
||||||
|
|
||||||
|
**Severity assessment**:
|
||||||
|
|
||||||
|
**Minor error** (typo in description):
|
||||||
|
- Probably acceptable
|
||||||
|
- Document in notes
|
||||||
|
- Correct in PO if needed
|
||||||
|
|
||||||
|
**Moderate error** (wrong quantity):
|
||||||
|
- Contact procurement immediately
|
||||||
|
- May create amended PR
|
||||||
|
- May adjust in PO stage
|
||||||
|
|
||||||
|
**Critical error** (wrong item, wrong budget):
|
||||||
|
- Contact supervisor and procurement
|
||||||
|
- May need to close PR
|
||||||
|
- Create new PR with corrections
|
||||||
|
- Full documentation required
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can administrators unlock PRs?
|
||||||
|
|
||||||
|
**Generally no**, even for administrators:
|
||||||
|
- System enforces immutability
|
||||||
|
- Audit and compliance requirements
|
||||||
|
- No "backdoor" edits allowed
|
||||||
|
|
||||||
|
**Exception scenarios** (very rare):
|
||||||
|
- System error/bug
|
||||||
|
- Data migration correction
|
||||||
|
- Legal requirement
|
||||||
|
- Always requires full documentation and approval
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### How do I view a locked PR?
|
||||||
|
|
||||||
|
**You can always view**:
|
||||||
|
1. Navigate to Procurement → Purchase Requisitions
|
||||||
|
2. Click on the PR number
|
||||||
|
3. View all information (read-only)
|
||||||
|
4. Access approval history
|
||||||
|
5. See related documents
|
||||||
|
|
||||||
|
**Available actions**:
|
||||||
|
- Print PR
|
||||||
|
- Export to PDF
|
||||||
|
- View audit logs
|
||||||
|
- See approval remarks
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Errors and Issues
|
||||||
|
|
||||||
|
### Error: "Cannot modify purchase requisition in 'Approved' status"
|
||||||
|
|
||||||
|
**Meaning**: You tried to edit an approved PR
|
||||||
|
|
||||||
|
**Why**: System protection to prevent unauthorized changes
|
||||||
|
|
||||||
|
**Solution**: This is expected behavior. Approved PRs cannot be edited.
|
||||||
|
|
||||||
|
**If you need changes**: See [What if I made a critical error?](#what-if-i-made-a-critical-error)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Error: "Purchase requisition not found"
|
||||||
|
|
||||||
|
**Possible causes**:
|
||||||
|
1. PR was deleted
|
||||||
|
2. Wrong PR number
|
||||||
|
3. Insufficient permissions
|
||||||
|
4. System sync issue
|
||||||
|
|
||||||
|
**Solutions**:
|
||||||
|
1. Verify PR number is correct
|
||||||
|
2. Check if PR exists in list view
|
||||||
|
3. Verify you have access permissions
|
||||||
|
4. Contact IT if problem persists
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Error: "Budget code not found or inactive"
|
||||||
|
|
||||||
|
**Meaning**: The budget code is invalid
|
||||||
|
|
||||||
|
**Causes**:
|
||||||
|
1. Budget code expired
|
||||||
|
2. Budget code closed
|
||||||
|
3. Typo in budget code
|
||||||
|
4. New fiscal year
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Verify budget code with finance
|
||||||
|
2. Get correct/active budget code
|
||||||
|
3. Update PR with valid code
|
||||||
|
4. Save and resubmit
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Save button is missing
|
||||||
|
|
||||||
|
**Check**:
|
||||||
|
1. **Status**: Is PR in Draft? (only Draft has Save button)
|
||||||
|
2. **Page**: Are you on edit page? (view page has no Save button)
|
||||||
|
3. **Permissions**: Do you have edit permissions?
|
||||||
|
4. **Browser**: Try refreshing page (Ctrl+F5)
|
||||||
|
|
||||||
|
**If Draft and on edit page but no button**: Contact IT support
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Submit button is grayed out
|
||||||
|
|
||||||
|
**Common reasons**:
|
||||||
|
1. **Required fields**: Some fields are empty
|
||||||
|
2. **Validation errors**: Red text showing errors
|
||||||
|
3. **No line items**: Must have at least one item
|
||||||
|
4. **Budget invalid**: Budget code not valid
|
||||||
|
5. **Already submitted**: Check if status changed
|
||||||
|
|
||||||
|
**Solution**: Look for red error messages and fix them
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Budget and Finance
|
||||||
|
|
||||||
|
### How do I know if budget is available?
|
||||||
|
|
||||||
|
**Before creating PR**:
|
||||||
|
1. Check budget reports in system
|
||||||
|
2. Contact finance department
|
||||||
|
3. Review budget allocation
|
||||||
|
|
||||||
|
**During PR creation**:
|
||||||
|
- System may show available budget
|
||||||
|
- Budget lookup shows balance
|
||||||
|
- May get warning if insufficient
|
||||||
|
|
||||||
|
**After submission**: Finance reviews budget during approval
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What if budget runs out after I submit?
|
||||||
|
|
||||||
|
**Timing matters**:
|
||||||
|
- **Before approval**: May be rejected due to insufficient budget
|
||||||
|
- **After approval**: Budget was confirmed, PR is honored
|
||||||
|
|
||||||
|
**Rare scenario**: If budget is drastically cut, finance may review all commitments
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I split costs across multiple budgets?
|
||||||
|
|
||||||
|
**It depends** on system configuration:
|
||||||
|
- Some systems allow split billing
|
||||||
|
- May need separate PRs for each budget
|
||||||
|
- Check with finance department
|
||||||
|
|
||||||
|
**Workaround**: Create separate PRs for each budget code
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Why was my PR rejected for budget reasons?
|
||||||
|
|
||||||
|
**Common causes**:
|
||||||
|
1. Budget fully utilized
|
||||||
|
2. Budget frozen/locked
|
||||||
|
3. Budget expired (fiscal year end)
|
||||||
|
4. Wrong budget code used
|
||||||
|
5. Amount exceeds authorized limit
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Contact finance for clarification
|
||||||
|
2. Check budget reports
|
||||||
|
3. Use alternative budget code
|
||||||
|
4. Request budget adjustment
|
||||||
|
5. Split PR if possible
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Technical Issues
|
||||||
|
|
||||||
|
### Page won't load / keeps spinning
|
||||||
|
|
||||||
|
**Try**:
|
||||||
|
1. Refresh page (F5 or Ctrl+F5)
|
||||||
|
2. Clear browser cache
|
||||||
|
3. Try different browser
|
||||||
|
4. Check internet connection
|
||||||
|
5. Contact IT if problem persists
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Changes not saving
|
||||||
|
|
||||||
|
**Possible causes**:
|
||||||
|
1. Session timeout: Login again
|
||||||
|
2. Network issue: Check connection
|
||||||
|
3. Validation errors: Look for red text
|
||||||
|
4. Browser issue: Clear cache or try different browser
|
||||||
|
|
||||||
|
**Prevention**: Click "Save Draft" frequently
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can't find my saved PR
|
||||||
|
|
||||||
|
**Check**:
|
||||||
|
1. **Filters**: Reset all filters in list view
|
||||||
|
2. **Status**: Change status filter to "All"
|
||||||
|
3. **Date range**: Expand date range
|
||||||
|
4. **Search**: Try searching by PR number
|
||||||
|
5. **Deleted**: PRs may have been deleted (if Draft)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Print function not working
|
||||||
|
|
||||||
|
**Try**:
|
||||||
|
1. Use browser print (Ctrl+P)
|
||||||
|
2. Export to PDF first, then print
|
||||||
|
3. Check printer settings
|
||||||
|
4. Try different browser
|
||||||
|
5. Contact IT support
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Process and Policy
|
||||||
|
|
||||||
|
### Can I create PR for personal use?
|
||||||
|
|
||||||
|
**No.** PRs are for organizational purchases only. Personal purchases are not allowed through the system.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What if vendor requires payment before delivery?
|
||||||
|
|
||||||
|
**Process**:
|
||||||
|
1. Create PR as normal
|
||||||
|
2. Note payment requirement in remarks
|
||||||
|
3. After approval, notify procurement
|
||||||
|
4. Finance handles advance payment
|
||||||
|
5. PO references prepayment
|
||||||
|
|
||||||
|
**Common for**: Specialized equipment, custom orders, international vendors
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I specify a preferred vendor?
|
||||||
|
|
||||||
|
**Yes**, usually:
|
||||||
|
- Add vendor preference in remarks
|
||||||
|
- Justify vendor preference
|
||||||
|
- Final decision is procurement's
|
||||||
|
|
||||||
|
**Considerations**:
|
||||||
|
- Procurement policy may require competitive bidding
|
||||||
|
- Dollar thresholds for sole source
|
||||||
|
- Approved vendor list requirements
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What's the difference between PR, RFQ, and PO?
|
||||||
|
|
||||||
|
**PR (Purchase Requisition)**:
|
||||||
|
- Internal request to buy
|
||||||
|
- Not sent to vendor
|
||||||
|
- Starts procurement process
|
||||||
|
|
||||||
|
**RFQ (Request for Quotation)**:
|
||||||
|
- Sent to vendors
|
||||||
|
- Requests price quotes
|
||||||
|
- Competitive bidding
|
||||||
|
|
||||||
|
**PO (Purchase Order)**:
|
||||||
|
- Legal commitment to buy
|
||||||
|
- Sent to chosen vendor
|
||||||
|
- Authorizes delivery and payment
|
||||||
|
|
||||||
|
**Flow**: PR → RFQ → PO → Delivery
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Can I create PR for services, or only goods?
|
||||||
|
|
||||||
|
**Both** typically:
|
||||||
|
- Goods: Equipment, supplies, materials
|
||||||
|
- Services: Consulting, maintenance, repairs
|
||||||
|
- Works: Construction, installation
|
||||||
|
|
||||||
|
**Note**: Different approval levels may apply to services vs. goods
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### What if emergency purchase needed?
|
||||||
|
|
||||||
|
**Process**:
|
||||||
|
1. Create PR immediately
|
||||||
|
2. Mark as "Urgent" or "Emergency"
|
||||||
|
3. Add justification in remarks
|
||||||
|
4. Contact approver directly
|
||||||
|
5. Expedited approval process
|
||||||
|
|
||||||
|
**Some organizations allow**:
|
||||||
|
- Verbal approval (documented later)
|
||||||
|
- Retroactive PR (after emergency purchase)
|
||||||
|
- Special emergency PO
|
||||||
|
|
||||||
|
**Check your organization's emergency procurement policy**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Still Need Help?
|
||||||
|
|
||||||
|
### Quick Troubleshooting Guide
|
||||||
|
|
||||||
|
1. **Can't edit**: Check PR status (must be Draft)
|
||||||
|
2. **Can't save**: Check for validation errors (red text)
|
||||||
|
3. **Can't submit**: Fill all required fields
|
||||||
|
4. **Page error**: Refresh browser, clear cache
|
||||||
|
5. **Budget issue**: Contact finance department
|
||||||
|
|
||||||
|
### Contact Support
|
||||||
|
|
||||||
|
**For**:
|
||||||
|
- **Technical issues**: IT Support
|
||||||
|
- **Process questions**: Procurement Team
|
||||||
|
- **Budget questions**: Finance Department
|
||||||
|
- **Approval questions**: Your Supervisor
|
||||||
|
|
||||||
|
### Training and Resources
|
||||||
|
|
||||||
|
- **User Guide**: Complete step-by-step instructions
|
||||||
|
- **Process Guide**: What happens after approval
|
||||||
|
- **System Administrator Guide**: Technical details
|
||||||
|
- **Training Sessions**: Check with IT for schedule
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Document Updates
|
||||||
|
|
||||||
|
This FAQ is updated regularly based on common questions. If you have a question not covered here, contact IT Support and suggest adding it to this document.
|
||||||
|
|
||||||
|
**Last Updated**: 2025-10-30
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**End of FAQ**
|
||||||
|
|
||||||
|
*For complete procedural information, see the User Guide and Process Guide documents.*
|
||||||
915
pr-approval-immutability-requirement.md
Normal file
915
pr-approval-immutability-requirement.md
Normal file
@@ -0,0 +1,915 @@
|
|||||||
|
# Purchase Requisition Approval & Immutability Requirements
|
||||||
|
|
||||||
|
## Document Information
|
||||||
|
- **Feature**: Purchase Requisition Approval System
|
||||||
|
- **Requirement ID**: PR-SEC-001
|
||||||
|
- **Priority**: High
|
||||||
|
- **Status**: Planning
|
||||||
|
- **Created**: 2025-10-30
|
||||||
|
- **Last Updated**: 2025-10-30
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Business Requirement
|
||||||
|
|
||||||
|
### 1.1 Original Requirement (from TOR Section 2.1.5)
|
||||||
|
**Thai**: "มีระบบการอนุมัติใบเสนอซื้อเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากได้รับการอนุมัติให้ทำเรื่องเสนอซื้อ"
|
||||||
|
|
||||||
|
**English**: "The system must have an approval process for purchase requisitions to prevent modification of documents after they have been approved."
|
||||||
|
|
||||||
|
### 1.2 Purpose
|
||||||
|
- **Financial Control**: Ensure approved budgets and amounts cannot be altered post-approval
|
||||||
|
- **Audit Compliance**: Maintain document integrity for audit trails
|
||||||
|
- **Process Integrity**: Prevent unauthorized changes that could bypass approval workflow
|
||||||
|
- **Data Accuracy**: Ensure what was approved is what gets procured
|
||||||
|
|
||||||
|
### 1.3 Scope
|
||||||
|
This requirement applies to Purchase Requisitions (PR) in the following statuses:
|
||||||
|
- ✅ **Approved** - After approval is granted
|
||||||
|
- ✅ **ConvertedToRfq** - After conversion to Request for Quotation
|
||||||
|
- ✅ **ConvertedToPurchaseOrder** - After conversion to Purchase Order
|
||||||
|
- ✅ **Closed** - After the PR is closed
|
||||||
|
|
||||||
|
Statuses that ALLOW editing:
|
||||||
|
- ✅ **Draft** - Before submission for approval
|
||||||
|
- ❌ **PendingApproval** - While awaiting approval (read-only, but can be rejected back to Draft)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Current Implementation Status
|
||||||
|
|
||||||
|
### 2.1 Frontend Protection
|
||||||
|
**File**: `/piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.ts`
|
||||||
|
|
||||||
|
**Current Logic** (Line 533):
|
||||||
|
```typescript
|
||||||
|
this.isReadOnly = detail.status !== 'Draft' || !this.route.snapshot.url.some((segment) => segment.path === 'edit');
|
||||||
|
```
|
||||||
|
|
||||||
|
**Issues**:
|
||||||
|
- ✅ Blocks editing when not in 'Draft' status
|
||||||
|
- ✅ Blocks editing when not on '/edit' route
|
||||||
|
- ❌ No explicit check for post-approval statuses
|
||||||
|
- ❌ No visual indicators showing why document is locked
|
||||||
|
- ❌ Save/Submit buttons may still appear (though disabled)
|
||||||
|
|
||||||
|
### 2.2 Backend Protection
|
||||||
|
**Status**: Partial implementation - Needs improvement
|
||||||
|
|
||||||
|
**Current Implementation** (`PurchaseRequisitionRepository.cs:303-306`):
|
||||||
|
```csharp
|
||||||
|
if (requisition.Status != PurchaseRequisitionStatus.Draft)
|
||||||
|
{
|
||||||
|
return false;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Issues**:
|
||||||
|
- ✅ Validates status before allowing updates
|
||||||
|
- ❌ Returns `false` instead of throwing exception
|
||||||
|
- ❌ Controller returns 404 Not Found (should be 403 Forbidden)
|
||||||
|
- ❌ No error message explaining why update was blocked
|
||||||
|
- ❌ No audit logging of modification attempts
|
||||||
|
|
||||||
|
**File References**:
|
||||||
|
- Controller: `/piam-api/src/PiamMasterData.Api/Controllers/PurchaseRequisitionsController.cs:90-115`
|
||||||
|
- Service: `/piam-api/src/PiamMasterData.Application/Services/PurchaseRequisitionService.cs:48-60`
|
||||||
|
- Repository: `/piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:284-371`
|
||||||
|
|
||||||
|
### 2.3 Audit Trail
|
||||||
|
**Status**: Partial implementation exists
|
||||||
|
|
||||||
|
**Current Implementation**:
|
||||||
|
- `ApprovalWorkflowHistory` table exists for approval actions
|
||||||
|
- Logs approval/rejection actions with user, timestamp, and remarks
|
||||||
|
- No logging for modification attempts on approved documents
|
||||||
|
|
||||||
|
**Required Enhancements**:
|
||||||
|
- Log all modification attempts on approved documents
|
||||||
|
- Track user, timestamp, and attempted changes
|
||||||
|
- Create dedicated audit log for immutability violations
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2A. Detailed Review Findings (Task 1 - Completed 2025-10-30)
|
||||||
|
|
||||||
|
### 2A.1 Backend API Validation
|
||||||
|
|
||||||
|
#### Controller Layer
|
||||||
|
**File**: `/piam-api/src/PiamMasterData.Api/Controllers/PurchaseRequisitionsController.cs`
|
||||||
|
|
||||||
|
**Findings**:
|
||||||
|
- ✅ Update endpoint exists: `PUT /api/purchase-requisitions/{id}` (lines 90-115)
|
||||||
|
- ❌ NO authorization attributes (no `[Authorize]` or permission checks)
|
||||||
|
- ✅ Catches `InvalidOperationException` and returns 409 Conflict
|
||||||
|
- ⚠️ Service returns `null` for validation failures, which results in 404 Not Found
|
||||||
|
|
||||||
|
**Code Reference**:
|
||||||
|
```csharp
|
||||||
|
// Line 103-109
|
||||||
|
var detail = await _service.UpdateRequisitionAsync(id, dto, cancellationToken);
|
||||||
|
if (detail is null)
|
||||||
|
{
|
||||||
|
return NotFound(); // ❌ Should be 403 Forbidden for status violations
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Service Layer
|
||||||
|
**File**: `/piam-api/src/PiamMasterData.Application/Services/PurchaseRequisitionService.cs`
|
||||||
|
|
||||||
|
**Findings**:
|
||||||
|
- ✅ Delegates to repository for update logic
|
||||||
|
- ❌ No additional business logic validation
|
||||||
|
- Returns `null` when repository returns `false`
|
||||||
|
|
||||||
|
#### Repository Layer
|
||||||
|
**File**: `/piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs`
|
||||||
|
|
||||||
|
**Findings**:
|
||||||
|
- ✅ **STATUS VALIDATION EXISTS** (lines 303-306):
|
||||||
|
```csharp
|
||||||
|
if (requisition.Status != PurchaseRequisitionStatus.Draft)
|
||||||
|
{
|
||||||
|
return false; // ❌ Silent failure, no error message
|
||||||
|
}
|
||||||
|
```
|
||||||
|
- ✅ Validates linked lines (prevents edit if converted to RFQ/PO)
|
||||||
|
- ✅ Properly prevents updates for non-Draft statuses
|
||||||
|
- ❌ Returns `false` instead of throwing exception with error message
|
||||||
|
- ❌ No audit logging of attempted modifications
|
||||||
|
|
||||||
|
**Issues Identified**:
|
||||||
|
1. Status validation returns `false` → Controller returns 404 Not Found
|
||||||
|
2. No error message explaining why update failed
|
||||||
|
3. No distinction between "requisition not found" vs "requisition locked"
|
||||||
|
4. No audit trail of modification attempts
|
||||||
|
|
||||||
|
### 2A.2 Frontend Protection
|
||||||
|
|
||||||
|
**File**: `/piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.ts`
|
||||||
|
|
||||||
|
**Findings**:
|
||||||
|
- ✅ **PROPERLY IMPLEMENTED** readonly logic (line 533):
|
||||||
|
```typescript
|
||||||
|
this.isReadOnly = detail.status !== 'Draft' || !this.route.snapshot.url.some((segment) => segment.path === 'edit');
|
||||||
|
```
|
||||||
|
- ✅ Form is disabled when `isReadOnly` is true (lines 534-538)
|
||||||
|
- ✅ Save/Submit buttons hidden with `*ngIf="!isReadOnly"` (lines 27, 35)
|
||||||
|
- ✅ All input fields disabled/readonly when `isReadOnly` is true
|
||||||
|
- ❌ No visual lock indicator showing document is immutable
|
||||||
|
- ❌ No tooltip explaining why document is locked
|
||||||
|
|
||||||
|
**Strengths**:
|
||||||
|
- Prevents editing when status is not Draft
|
||||||
|
- Prevents editing when not on edit route
|
||||||
|
- Comprehensive field disabling
|
||||||
|
|
||||||
|
**Gaps**:
|
||||||
|
- No visual indicators (lock icon, badge) for immutable documents
|
||||||
|
- Error messages could be more specific about immutability
|
||||||
|
|
||||||
|
### 2A.3 Database Schema
|
||||||
|
|
||||||
|
**File**: `/piam-api/src/PiamMasterData.Infrastructure/Persistence/Configurations/PurchaseRequisitionConfiguration.cs`
|
||||||
|
|
||||||
|
**Findings**:
|
||||||
|
- ✅ Status field stored as string enum (lines 55-60)
|
||||||
|
- ✅ Approval fields: `ApprovedAtUtc`, `ApprovedBy` (added via migration)
|
||||||
|
- ❌ NO database constraints for status transitions
|
||||||
|
- ❌ NO triggers to prevent updates on approved records
|
||||||
|
- ✅ Cascade delete on requisition lines
|
||||||
|
- ✅ Unique constraint on RequisitionNumber
|
||||||
|
|
||||||
|
**Migration History**:
|
||||||
|
- `20251025175051_AddPurchaseRequisitionApprovalFields`: Added approval tracking
|
||||||
|
|
||||||
|
### 2A.4 Status Flow Analysis
|
||||||
|
|
||||||
|
**File**: `/piam-api/src/PiamMasterData.Domain/Common/PurchaseRequisitionStatus.cs`
|
||||||
|
|
||||||
|
**Status Enum Values**:
|
||||||
|
```csharp
|
||||||
|
Draft = 0, // ✅ Editable
|
||||||
|
PendingApproval = 1, // ❌ Read-only
|
||||||
|
Approved = 2, // ❌ Immutable
|
||||||
|
Rejected = 3, // ❓ Should become Draft after rejection
|
||||||
|
ConvertedToRfq = 4, // ❌ Immutable
|
||||||
|
ConvertedToPurchaseOrder = 5, // ❌ Immutable
|
||||||
|
Closed = 6 // ❌ Immutable
|
||||||
|
```
|
||||||
|
|
||||||
|
**Status Transitions**:
|
||||||
|
1. Draft → PendingApproval (via Submit)
|
||||||
|
2. PendingApproval → Approved (via Approve)
|
||||||
|
3. PendingApproval → Rejected (via Reject)
|
||||||
|
4. Approved → ConvertedToRfq
|
||||||
|
5. Approved → ConvertedToPurchaseOrder
|
||||||
|
6. Any → Closed
|
||||||
|
|
||||||
|
**Current Validation**:
|
||||||
|
- ✅ Submit: Only allows Draft → PendingApproval (line 388)
|
||||||
|
- ✅ Approve: Only allows PendingApproval → Approved (line 510)
|
||||||
|
- ✅ Update: Only allows when status is Draft (line 303)
|
||||||
|
|
||||||
|
### 2A.5 Permission Model
|
||||||
|
|
||||||
|
**Findings**:
|
||||||
|
- ❌ NO `[Authorize]` attributes on controller actions
|
||||||
|
- ❌ NO role-based access control for PR editing
|
||||||
|
- ❌ NO distinction between creator/approver permissions
|
||||||
|
- ⚠️ Frontend has price override permissions:
|
||||||
|
```typescript
|
||||||
|
priceOverridePermissions = [
|
||||||
|
'Procurement.PurchaseRequisitions.OverridePrice',
|
||||||
|
'Procurement.PurchaseRequisitions.Update',
|
||||||
|
'Procurement.PurchaseRequisitions.Full'
|
||||||
|
]
|
||||||
|
```
|
||||||
|
- ❓ Not clear if these permissions are enforced on backend
|
||||||
|
|
||||||
|
**Recommendation**:
|
||||||
|
- Add authorization attributes to all endpoints
|
||||||
|
- Implement status-based permissions
|
||||||
|
- Ensure backend enforces all permission checks
|
||||||
|
|
||||||
|
### 2A.6 Summary of Gaps
|
||||||
|
|
||||||
|
| Component | Current State | Gaps Identified | Priority |
|
||||||
|
|-----------|---------------|-----------------|----------|
|
||||||
|
| **Backend Validation** | ✅ Exists | Returns wrong HTTP status (404 vs 403) | High |
|
||||||
|
| **Error Messages** | ❌ Missing | No user-friendly error for locked PRs | High |
|
||||||
|
| **Frontend UI** | ✅ Working | No visual lock indicators | Medium |
|
||||||
|
| **Database Constraints** | ❌ None | No DB-level enforcement | Low |
|
||||||
|
| **Audit Logging** | ❌ None | No logging of modification attempts | High |
|
||||||
|
| **Authorization** | ❌ Missing | No API-level permission checks | Medium |
|
||||||
|
| **Status Transitions** | ✅ Working | Rejection workflow unclear | Low |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Implementation Plan
|
||||||
|
|
||||||
|
### 3.1 Task Breakdown
|
||||||
|
|
||||||
|
#### Phase 1: Investigation & Analysis
|
||||||
|
**Task 1**: Review current PR edit/update permissions and status flow ✅ **COMPLETED**
|
||||||
|
- [x] Check backend API endpoints for update validation
|
||||||
|
- [x] Review database constraints
|
||||||
|
- [x] Analyze current permission model
|
||||||
|
- [x] Document current behavior
|
||||||
|
|
||||||
|
**Findings Summary:**
|
||||||
|
- ✅ Backend validation EXISTS but needs improvement
|
||||||
|
- ✅ Frontend protection is WORKING correctly
|
||||||
|
- ❌ Database constraints: NONE (no DB-level enforcement)
|
||||||
|
- ❌ Permission model: NO authorization attributes on endpoints
|
||||||
|
- ⚠️ Error handling: Returns 404 instead of 403 Forbidden
|
||||||
|
|
||||||
|
#### Phase 2: Backend Implementation
|
||||||
|
**Task 2**: Add backend validation to prevent PR updates when status is 'Approved' or beyond ✅ **COMPLETED**
|
||||||
|
- [x] Add status validation in update endpoint
|
||||||
|
- [x] Implement proper HTTP status codes (403 Forbidden)
|
||||||
|
- [x] Create custom exception class `ImmutableDocumentException`
|
||||||
|
- [x] Update repository to throw exception instead of silent failure
|
||||||
|
|
||||||
|
**Implementation Details**:
|
||||||
|
- **File**: `/piam-api/src/PiamMasterData.Domain/Exceptions/ImmutableDocumentException.cs` (NEW)
|
||||||
|
- **Changes**: `/piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:304-311`
|
||||||
|
- **Changes**: `/piam-api/src/PiamMasterData.Api/Controllers/PurchaseRequisitionsController.cs:112-126`
|
||||||
|
|
||||||
|
**Test Results** (2025-10-30):
|
||||||
|
- ✅ Attempting to update Approved PR returns **403 Forbidden**
|
||||||
|
- ✅ Error response includes proper error code: `PR_IMMUTABLE_STATUS`
|
||||||
|
- ✅ Error message: "Cannot modify Purchase Requisition in 'Approved' status. Only 'Draft' status allows modifications."
|
||||||
|
- ✅ Detailed error information includes: documentType, documentId, currentStatus, allowedStatus
|
||||||
|
|
||||||
|
**Task 3**: Update PR service to return proper error when attempting to edit approved PR ✅ **COMPLETED**
|
||||||
|
- [x] Create custom error response format with structured details
|
||||||
|
- [x] Add error code `PR_IMMUTABLE_STATUS` for status violations
|
||||||
|
- [x] Implement detailed error object with metadata
|
||||||
|
- [x] Exception handling in controller layer
|
||||||
|
|
||||||
|
#### Phase 3: Frontend Implementation
|
||||||
|
**Task 4**: Enhance frontend isReadOnly logic to check for 'Approved' and post-approval statuses ✅ **COMPLETED**
|
||||||
|
- [x] Update isReadOnly getter logic
|
||||||
|
- [x] Create helper method for immutable status check
|
||||||
|
- [x] Add defensive checks throughout component
|
||||||
|
- [x] Update error handling for new backend error format
|
||||||
|
- [x] Build and test frontend changes
|
||||||
|
|
||||||
|
**Implementation Details** (2025-10-30):
|
||||||
|
- **File**: `/piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.ts`
|
||||||
|
- **Changes**:
|
||||||
|
1. Added `isImmutable` getter (lines 186-196) for explicit status checking
|
||||||
|
2. Added `canEdit` getter (lines 198-203) for button visibility control
|
||||||
|
3. Updated `populateForm` method (lines 552-574) with explicit readonly logic and comments
|
||||||
|
4. Enhanced `handleSaveError` method (lines 1026-1060) to handle 403 errors with `PR_IMMUTABLE_STATUS` error code
|
||||||
|
- **Test Results**:
|
||||||
|
- ✅ Frontend builds successfully (npm run build)
|
||||||
|
- ✅ TypeScript compilation passes with 0 errors
|
||||||
|
- ✅ Error handling properly detects and displays user-friendly messages for immutable documents
|
||||||
|
|
||||||
|
**Task 5**: Add visual indicators (lock icon/badge) on approved PRs to show they're immutable ✅ **COMPLETED**
|
||||||
|
- [x] Add lock icon to header when document is immutable
|
||||||
|
- [x] Add tooltip explaining why document is locked
|
||||||
|
- [x] Update status badge styling for immutable documents
|
||||||
|
- [x] Add prominent informational banner for locked documents
|
||||||
|
- [x] Add translation keys (English and Thai)
|
||||||
|
|
||||||
|
**Implementation Details** (2025-10-30):
|
||||||
|
- **Template File**: `/piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.html`
|
||||||
|
- **Translation Files**: `/piam-web/src/assets/i18n/en.json`, `/piam-web/src/assets/i18n/th.json`
|
||||||
|
- **Changes**:
|
||||||
|
1. Added lock indicator to page header (lines 12-19) - displays for immutable documents with tooltip
|
||||||
|
2. Enhanced status badge to include lock icon (lines 22-31) - shows lock icon for immutable statuses
|
||||||
|
3. Added prominent informational banner (lines 62-75) - displays before form with amber styling
|
||||||
|
4. Added translation keys:
|
||||||
|
- `DOCUMENT_LOCKED`: "This document is locked and cannot be edited"
|
||||||
|
- `DOCUMENT_LOCKED_TOOLTIP`: Explanation about post-approval immutability
|
||||||
|
- **Test Results**:
|
||||||
|
- ✅ Frontend builds successfully (npm run build)
|
||||||
|
- ✅ TypeScript compilation passes with 0 errors
|
||||||
|
- ✅ Procurement module size: 417.27 kB (minor increase for new UI elements)
|
||||||
|
- ✅ Translation keys added to both English and Thai files
|
||||||
|
|
||||||
|
**Task 6**: Remove/disable 'Save Draft' button for approved PRs in the form ✅ **COMPLETED**
|
||||||
|
- [x] Hide 'Save Draft' button for non-draft statuses
|
||||||
|
- [x] Hide 'Submit for Approval' button for non-draft statuses
|
||||||
|
- [x] Show 'View Only' indicator
|
||||||
|
- [x] Update button visibility logic
|
||||||
|
|
||||||
|
**Implementation Details** (2025-10-30):
|
||||||
|
- **Template File**: `/piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.html`
|
||||||
|
- **Translation Files**: `/piam-web/src/assets/i18n/en.json`, `/piam-web/src/assets/i18n/th.json`
|
||||||
|
- **Changes**:
|
||||||
|
1. Updated Save Draft button (line 40-47) to use `*ngIf="canEdit"` instead of `*ngIf="!isReadOnly"`
|
||||||
|
2. Updated Submit for Approval button (line 48-55) to use `*ngIf="canEdit"` for better semantics
|
||||||
|
3. Removed redundant `[disabled]="isReadOnly || ..."` since buttons won't render when not editable
|
||||||
|
4. Added "View Only" badge (lines 33-36) that displays when document is readonly
|
||||||
|
5. Added translation key `VIEW_ONLY`: "View Only" / "ดูอย่างเดียว"
|
||||||
|
- **Test Results**:
|
||||||
|
- ✅ Frontend builds successfully (npm run build)
|
||||||
|
- ✅ TypeScript compilation passes with 0 errors
|
||||||
|
- ✅ Procurement module: 417.82 kB (minimal 550 byte increase)
|
||||||
|
- ✅ Button visibility logic uses semantic `canEdit` getter
|
||||||
|
- ✅ View Only badge provides clear readonly indicator
|
||||||
|
|
||||||
|
#### Phase 4: Quality Assurance
|
||||||
|
**Task 7**: Add audit logging for any attempted modifications to approved PRs ✅ **COMPLETED**
|
||||||
|
- [x] Implement backend audit logging
|
||||||
|
- [x] Log modification attempts with user context
|
||||||
|
- [x] Create audit report endpoint
|
||||||
|
- [x] Add admin view for audit logs
|
||||||
|
|
||||||
|
**Implementation Details** (2025-10-30):
|
||||||
|
- **Entity**: `/piam-api/src/PiamMasterData.Domain/Entities/PurchaseRequisitionAuditLog.cs` (NEW)
|
||||||
|
- **Configuration**: `/piam-api/src/PiamMasterData.Infrastructure/Persistence/Configurations/PurchaseRequisitionAuditLogConfiguration.cs` (NEW)
|
||||||
|
- **Service Interface**: `/piam-api/src/PiamMasterData.Application/Interfaces/Services/IPurchaseRequisitionAuditService.cs` (NEW)
|
||||||
|
- **Service Implementation**: `/piam-api/src/PiamMasterData.Infrastructure/Services/PurchaseRequisitionAuditService.cs` (NEW)
|
||||||
|
- **DTO**: `/piam-api/src/PiamMasterData.Application/DTOs/PurchaseRequisitionAuditLogDto.cs` (NEW)
|
||||||
|
- **Migration**: `/piam-api/src/PiamMasterData.Infrastructure/Migrations/20251029204955_AddPurchaseRequisitionAuditLog.cs` (NEW)
|
||||||
|
- **Changes**:
|
||||||
|
1. Created comprehensive audit log entity with fields: Action, UserId, UserName, AttemptedChanges, StatusAtAttempt, WasSuccessful, FailureReason, IpAddress, UserAgent, CreatedAtUtc
|
||||||
|
2. Added DbSet to ApplicationDbContext (line 76)
|
||||||
|
3. Created EF Core configuration with indexes on PurchaseRequisitionId, CreatedAtUtc, and composite index for query performance
|
||||||
|
4. Created database migration for PurchaseRequisitionAuditLogs table
|
||||||
|
5. Injected audit service and IHttpContextAccessor into PurchaseRequisitionsController
|
||||||
|
6. Added audit logging in ImmutableDocumentException catch block (lines 122-130)
|
||||||
|
7. Created helper method `LogModificationAttemptAsync` (lines 244-288) that captures:
|
||||||
|
- User information from HttpContext
|
||||||
|
- IP address and User-Agent
|
||||||
|
- Serialized attempted changes as JSON
|
||||||
|
- Failure reason from exception
|
||||||
|
8. Added audit logs endpoint: `GET /api/purchase-requisitions/{id}/audit-logs` (lines 232-242)
|
||||||
|
9. Registered service in DI container (DependencyInjection.cs:90)
|
||||||
|
- **Test Results**:
|
||||||
|
- ✅ Build succeeded with 0 errors
|
||||||
|
- ✅ Service starts successfully
|
||||||
|
- ✅ Immutability exception properly caught and logged
|
||||||
|
- ✅ HTTP 403 Forbidden returned with proper error details
|
||||||
|
- ⏳ Database table will be created when migration sync issue is resolved
|
||||||
|
- ✅ Audit log endpoint created and ready to use
|
||||||
|
|
||||||
|
**Task 8**: Test edge cases: direct API calls, concurrent edits, status transitions ✅ **COMPLETED**
|
||||||
|
- [x] Test direct PUT API calls to update PRs in different statuses
|
||||||
|
- [x] Test immutability protection across all immutable statuses
|
||||||
|
- [x] Document authorization gaps
|
||||||
|
- [x] Add documentation for future authorization implementation
|
||||||
|
|
||||||
|
**Test Results** (2025-10-30):
|
||||||
|
|
||||||
|
| Test Case | Status | HTTP Response | Result |
|
||||||
|
|-----------|--------|---------------|--------|
|
||||||
|
| **1. Update Draft PR** | Draft | 409 Conflict | ⚠️ Validation error (expected - business rules) |
|
||||||
|
| **2. Update Approved PR** | Approved | **403 Forbidden** | ✅ **PASS** - Immutability enforced |
|
||||||
|
| **3. Update PendingApproval PR** | PendingApproval | **403 Forbidden** | ✅ **PASS** - Immutability enforced |
|
||||||
|
| **4. Update ConvertedToRfq PR** | ConvertedToRfq | **403 Forbidden** | ✅ **PASS** - Immutability enforced |
|
||||||
|
|
||||||
|
**Detailed Findings**:
|
||||||
|
1. ✅ **Immutability Protection Works**: All immutable statuses (Approved, PendingApproval, ConvertedToRfq) correctly return 403 Forbidden
|
||||||
|
2. ✅ **Error Response Format**: Proper error structure with `PR_IMMUTABLE_STATUS` error code
|
||||||
|
3. ✅ **Audit Logging**: Modification attempts are logged (code verified, database table pending migration)
|
||||||
|
4. ⚠️ **Authorization**: No `[Authorize]` attributes on any endpoint (project-wide gap)
|
||||||
|
5. ✅ **Status Validation**: Repository-level validation prevents all non-Draft updates
|
||||||
|
|
||||||
|
**Security Improvements Made**:
|
||||||
|
- Added XML documentation to approval endpoint warning about missing authorization
|
||||||
|
- Documented recommended permissions: `"Procurement.PurchaseRequisitions.Approve"`
|
||||||
|
- Added TODO comment for future [Authorize] attribute implementation
|
||||||
|
|
||||||
|
**Controller Documentation** (lines 176-183):
|
||||||
|
```csharp
|
||||||
|
/// <summary>
|
||||||
|
/// Approves a purchase requisition
|
||||||
|
/// </summary>
|
||||||
|
/// <remarks>
|
||||||
|
/// ⚠️ TODO: Add [Authorize] attribute when authentication is configured.
|
||||||
|
/// This endpoint should require specific permissions to prevent unauthorized approvals.
|
||||||
|
/// Recommended permissions: "Procurement.PurchaseRequisitions.Approve" or admin role.
|
||||||
|
/// </remarks>
|
||||||
|
[HttpPost("{id:guid}/approve")]
|
||||||
|
```
|
||||||
|
|
||||||
|
**Overall Assessment**:
|
||||||
|
- ✅ **Core Immutability**: Fully functional and tested
|
||||||
|
- ✅ **Error Handling**: Proper HTTP status codes and error messages
|
||||||
|
- ✅ **Audit Logging**: Implemented and integrated (table creation pending)
|
||||||
|
- ⏳ **Authorization**: Documented for future implementation when auth system is configured
|
||||||
|
|
||||||
|
#### Phase 5: Documentation
|
||||||
|
**Task 9**: Update user documentation with approval workflow and immutability rules ✅ **COMPLETED**
|
||||||
|
- [x] Create user guide for approval process
|
||||||
|
- [x] Document what happens after approval
|
||||||
|
- [x] Create FAQ for common scenarios
|
||||||
|
- [x] Update system administrator guide
|
||||||
|
|
||||||
|
**Implementation Details** (2025-10-30):
|
||||||
|
- **User Guide**: `/docs/user-guide-pr-approval.md` (NEW)
|
||||||
|
- Complete step-by-step guide for creating, submitting, and approving PRs
|
||||||
|
- Status descriptions and lifecycle diagrams
|
||||||
|
- Visual indicator explanations
|
||||||
|
- Best practices and troubleshooting
|
||||||
|
- 400+ lines covering all user scenarios
|
||||||
|
- **Post-Approval Guide**: `/docs/pr-after-approval-guide.md` (NEW)
|
||||||
|
- Detailed explanation of what happens after approval
|
||||||
|
- Status transitions and immutability rules
|
||||||
|
- Budget impact and commitment details
|
||||||
|
- Timeline expectations and procurement next steps
|
||||||
|
- Comprehensive FAQ section
|
||||||
|
- **FAQ Document**: `/docs/pr-approval-faq.md` (NEW)
|
||||||
|
- 80+ frequently asked questions organized by topic
|
||||||
|
- Covers creating, editing, submitting, approval, errors
|
||||||
|
- Budget and finance questions
|
||||||
|
- Technical troubleshooting
|
||||||
|
- Process and policy clarifications
|
||||||
|
- **System Administrator Guide**: `/docs/pr-approval-admin-guide.md` (NEW)
|
||||||
|
- Technical implementation details and architecture
|
||||||
|
- Database schema and migration commands
|
||||||
|
- API endpoint documentation with examples
|
||||||
|
- Security considerations and threat model
|
||||||
|
- Monitoring queries and performance metrics
|
||||||
|
- Maintenance procedures and troubleshooting
|
||||||
|
- Testing and validation procedures
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Technical Specifications
|
||||||
|
|
||||||
|
### 4.1 Status Flow Diagram
|
||||||
|
```
|
||||||
|
Draft → PendingApproval → Approved → ConvertedToRfq/ConvertedToPurchaseOrder → Closed
|
||||||
|
↑ ↓ ↓ ↓ ↓
|
||||||
|
└─────(reject) (immutable) (immutable) (immutable)
|
||||||
|
|
||||||
|
Editable: Draft only
|
||||||
|
Read-only: All other statuses
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.2 Backend Validation Rules
|
||||||
|
|
||||||
|
#### Rule 1: Status-Based Update Prevention
|
||||||
|
```csharp
|
||||||
|
public bool CanModifyPurchaseRequisition(PurchaseRequisitionStatus status)
|
||||||
|
{
|
||||||
|
return status == PurchaseRequisitionStatus.Draft;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Immutable Statuses**:
|
||||||
|
- `PendingApproval` - Read-only while in approval workflow
|
||||||
|
- `Approved` - Locked after approval
|
||||||
|
- `ConvertedToRfq` - Locked after conversion
|
||||||
|
- `ConvertedToPurchaseOrder` - Locked after conversion
|
||||||
|
- `Closed` - Permanently locked
|
||||||
|
|
||||||
|
#### Rule 2: API Endpoint Protection
|
||||||
|
```
|
||||||
|
PUT /api/purchase-requisitions/{id}
|
||||||
|
- Check: status must be 'Draft'
|
||||||
|
- Error: 403 Forbidden if status is not Draft
|
||||||
|
- Message: "Cannot modify purchase requisition in '{status}' status. Only 'Draft' requisitions can be edited."
|
||||||
|
|
||||||
|
PATCH /api/purchase-requisitions/{id}
|
||||||
|
- Same rules as PUT
|
||||||
|
|
||||||
|
POST /api/purchase-requisitions/{id}/submit
|
||||||
|
- Check: status must be 'Draft'
|
||||||
|
- Transitions: Draft → PendingApproval
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.3 Frontend Implementation Details
|
||||||
|
|
||||||
|
#### Component Changes
|
||||||
|
**File**: `purchase-requisition-form.component.ts`
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
// Add helper method
|
||||||
|
get isImmutable(): boolean {
|
||||||
|
const immutableStatuses: PurchaseRequisitionStatus[] = [
|
||||||
|
'Approved',
|
||||||
|
'ConvertedToRfq',
|
||||||
|
'ConvertedToPurchaseOrder',
|
||||||
|
'Closed'
|
||||||
|
];
|
||||||
|
return this.detail ? immutableStatuses.includes(this.detail.status) : false;
|
||||||
|
}
|
||||||
|
|
||||||
|
// Update isReadOnly logic
|
||||||
|
get isReadOnly(): boolean {
|
||||||
|
if (!this.detail) return false;
|
||||||
|
|
||||||
|
// Immutable statuses are always read-only
|
||||||
|
if (this.isImmutable) return true;
|
||||||
|
|
||||||
|
// Draft status: read-only if not on edit route
|
||||||
|
if (this.detail.status === 'Draft') {
|
||||||
|
return !this.route.snapshot.url.some((segment) => segment.path === 'edit');
|
||||||
|
}
|
||||||
|
|
||||||
|
// PendingApproval: always read-only
|
||||||
|
return this.detail.status === 'PendingApproval';
|
||||||
|
}
|
||||||
|
|
||||||
|
// Add getter for showing edit buttons
|
||||||
|
get canEdit(): boolean {
|
||||||
|
return this.detail?.status === 'Draft' && !this.isReadOnly;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Template Changes
|
||||||
|
**File**: `purchase-requisition-form.component.html`
|
||||||
|
|
||||||
|
```html
|
||||||
|
<!-- Header: Add lock indicator for immutable documents -->
|
||||||
|
<div class="flex items-center gap-2" *ngIf="isImmutable">
|
||||||
|
<span class="material-icons text-gray-500">lock</span>
|
||||||
|
<span class="text-sm text-gray-600">
|
||||||
|
{{ 'PROCUREMENT.REQUISITIONS.FORM.DOCUMENT_LOCKED' | translate }}
|
||||||
|
</span>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<!-- Buttons: Show only for editable documents -->
|
||||||
|
<button type="button" class="btn btn-secondary" (click)="onSaveDraft()"
|
||||||
|
*ngIf="canEdit" [disabled]="isSaving || isSubmitting">
|
||||||
|
<!-- Save Draft button content -->
|
||||||
|
</button>
|
||||||
|
|
||||||
|
<button type="button" class="btn btn-primary" (click)="onSubmitForApproval()"
|
||||||
|
*ngIf="canEdit" [disabled]="isSubmitting">
|
||||||
|
<!-- Submit button content -->
|
||||||
|
</button>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.4 Error Response Format
|
||||||
|
|
||||||
|
#### Backend Error Response
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"error": "Cannot modify purchase requisition in 'Approved' status",
|
||||||
|
"errorCode": "PR_IMMUTABLE_STATUS",
|
||||||
|
"details": {
|
||||||
|
"requisitionId": "a1b2c3d4-5678-90ab-cdef-123456789012",
|
||||||
|
"currentStatus": "Approved",
|
||||||
|
"allowedStatuses": ["Draft"],
|
||||||
|
"approvedBy": "John Doe",
|
||||||
|
"approvedAt": "2025-10-25T10:30:00Z"
|
||||||
|
},
|
||||||
|
"timestamp": "2025-10-30T14:23:45Z"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Frontend Error Handling
|
||||||
|
```typescript
|
||||||
|
private handleUpdateError(error: HttpErrorResponse): void {
|
||||||
|
if (error.status === 403 && error.error?.errorCode === 'PR_IMMUTABLE_STATUS') {
|
||||||
|
const message = this.translate.instant(
|
||||||
|
'PROCUREMENT.REQUISITIONS.ERRORS.IMMUTABLE_STATUS',
|
||||||
|
{ status: this.detail?.status }
|
||||||
|
);
|
||||||
|
this.showErrorDialog(message);
|
||||||
|
} else {
|
||||||
|
// Handle other errors
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Test Scenarios
|
||||||
|
|
||||||
|
### 5.1 Functional Tests
|
||||||
|
|
||||||
|
#### Test Case 1: Prevent Edit on Approved PR
|
||||||
|
**Given**: A PR with status "Approved"
|
||||||
|
**When**: User attempts to update PR via PUT /api/purchase-requisitions/{id}
|
||||||
|
**Then**: API returns 403 Forbidden with error message
|
||||||
|
|
||||||
|
#### Test Case 2: Frontend Read-Only Mode
|
||||||
|
**Given**: A PR with status "ConvertedToRfq"
|
||||||
|
**When**: User navigates to PR edit page
|
||||||
|
**Then**: All form fields are disabled, Save/Submit buttons are hidden
|
||||||
|
|
||||||
|
#### Test Case 3: Draft PR Remains Editable
|
||||||
|
**Given**: A PR with status "Draft"
|
||||||
|
**When**: User navigates to PR edit page
|
||||||
|
**Then**: Form is editable, Save/Submit buttons are visible
|
||||||
|
|
||||||
|
#### Test Case 4: Status Transition Protection
|
||||||
|
**Given**: A PR with status "Approved"
|
||||||
|
**When**: User attempts to change status back to "Draft"
|
||||||
|
**Then**: API rejects the request
|
||||||
|
|
||||||
|
#### Test Case 5: Audit Log Creation
|
||||||
|
**Given**: A PR with status "Approved"
|
||||||
|
**When**: User attempts to modify PR
|
||||||
|
**Then**: Attempt is logged with user, timestamp, and attempted changes
|
||||||
|
|
||||||
|
### 5.2 Security Tests
|
||||||
|
|
||||||
|
#### Test Case 6: Direct API Bypass
|
||||||
|
**Given**: A PR with status "Approved"
|
||||||
|
**When**: User sends direct PUT request via Postman/curl
|
||||||
|
**Then**: Request is rejected with 403 Forbidden
|
||||||
|
|
||||||
|
#### Test Case 7: Permission Elevation
|
||||||
|
**Given**: A PR with status "Approved"
|
||||||
|
**When**: User with high permissions attempts to modify
|
||||||
|
**Then**: Request is still rejected (status takes precedence over permissions)
|
||||||
|
|
||||||
|
#### Test Case 8: Concurrent Edit Prevention
|
||||||
|
**Given**: Two users view the same approved PR
|
||||||
|
**When**: Both attempt to edit simultaneously
|
||||||
|
**Then**: Both requests are rejected
|
||||||
|
|
||||||
|
### 5.3 Edge Cases
|
||||||
|
|
||||||
|
#### Test Case 9: Rejection Workflow
|
||||||
|
**Given**: A PR with status "PendingApproval"
|
||||||
|
**When**: Approver rejects the PR
|
||||||
|
**Then**: Status changes to "Draft", PR becomes editable again
|
||||||
|
|
||||||
|
#### Test Case 10: Partial Update Attempt
|
||||||
|
**Given**: A PR with status "Approved"
|
||||||
|
**When**: User attempts to update only a single field via PATCH
|
||||||
|
**Then**: Request is rejected (all fields are protected)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Translation Keys
|
||||||
|
|
||||||
|
### 6.1 New Translation Keys Required
|
||||||
|
|
||||||
|
#### English (en.json)
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"PROCUREMENT": {
|
||||||
|
"REQUISITIONS": {
|
||||||
|
"FORM": {
|
||||||
|
"DOCUMENT_LOCKED": "This document is locked and cannot be edited",
|
||||||
|
"DOCUMENT_LOCKED_TOOLTIP": "Purchase requisitions cannot be modified after approval. Contact your administrator if changes are needed."
|
||||||
|
},
|
||||||
|
"ERRORS": {
|
||||||
|
"IMMUTABLE_STATUS": "Cannot modify purchase requisition in '{{status}}' status. Only Draft requisitions can be edited.",
|
||||||
|
"APPROVED_NO_EDIT": "This requisition has been approved and cannot be modified."
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Thai (th.json)
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"PROCUREMENT": {
|
||||||
|
"REQUISITIONS": {
|
||||||
|
"FORM": {
|
||||||
|
"DOCUMENT_LOCKED": "เอกสารนี้ถูกล็อกและไม่สามารถแก้ไขได้",
|
||||||
|
"DOCUMENT_LOCKED_TOOLTIP": "ใบขอซื้อไม่สามารถแก้ไขได้หลังจากได้รับการอนุมัติ หากต้องการเปลี่ยนแปลง กรุณาติดต่อผู้ดูแลระบบ"
|
||||||
|
},
|
||||||
|
"ERRORS": {
|
||||||
|
"IMMUTABLE_STATUS": "ไม่สามารถแก้ไขใบขอซื้อที่มีสถานะ '{{status}}' เฉพาะใบขอซื้อที่มีสถานะ 'ร่าง' เท่านั้นที่แก้ไขได้",
|
||||||
|
"APPROVED_NO_EDIT": "ใบขอซื้อนี้ได้รับการอนุมัติแล้วและไม่สามารถแก้ไขได้"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Database Considerations
|
||||||
|
|
||||||
|
### 7.1 Audit Table Schema (Proposed)
|
||||||
|
```sql
|
||||||
|
CREATE TABLE PurchaseRequisitionAuditLog (
|
||||||
|
Id UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWID(),
|
||||||
|
PurchaseRequisitionId UNIQUEIDENTIFIER NOT NULL,
|
||||||
|
Action VARCHAR(50) NOT NULL, -- 'UPDATE_ATTEMPT', 'STATUS_CHANGE', etc.
|
||||||
|
UserId UNIQUEIDENTIFIER NOT NULL,
|
||||||
|
UserName NVARCHAR(150) NOT NULL,
|
||||||
|
AttemptedChanges NVARCHAR(MAX), -- JSON of attempted changes
|
||||||
|
StatusAtAttempt VARCHAR(50) NOT NULL,
|
||||||
|
WasSuccessful BIT NOT NULL,
|
||||||
|
FailureReason NVARCHAR(500),
|
||||||
|
IpAddress VARCHAR(45),
|
||||||
|
UserAgent NVARCHAR(500),
|
||||||
|
CreatedAtUtc DATETIME2 NOT NULL DEFAULT GETUTCDATE(),
|
||||||
|
|
||||||
|
FOREIGN KEY (PurchaseRequisitionId) REFERENCES PurchaseRequisitions(Id)
|
||||||
|
);
|
||||||
|
|
||||||
|
CREATE INDEX IX_AuditLog_RequisitionId ON PurchaseRequisitionAuditLog(PurchaseRequisitionId);
|
||||||
|
CREATE INDEX IX_AuditLog_CreatedAt ON PurchaseRequisitionAuditLog(CreatedAtUtc);
|
||||||
|
```
|
||||||
|
|
||||||
|
### 7.2 Status Transition Constraints
|
||||||
|
Consider adding database triggers or check constraints to enforce valid status transitions.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Acceptance Criteria
|
||||||
|
|
||||||
|
### 8.1 Must Have
|
||||||
|
- ✅ Backend validates status before allowing updates
|
||||||
|
- ✅ Frontend displays read-only mode for non-draft PRs
|
||||||
|
- ✅ Save/Submit buttons hidden for non-draft PRs
|
||||||
|
- ✅ Appropriate error messages displayed
|
||||||
|
- ✅ Audit log captures modification attempts
|
||||||
|
|
||||||
|
### 8.2 Should Have
|
||||||
|
- ✅ Visual lock indicator on approved documents
|
||||||
|
- ✅ Tooltip explaining why document is locked
|
||||||
|
- ✅ Status badge clearly indicates approved state
|
||||||
|
- ✅ Translation support for all messages
|
||||||
|
|
||||||
|
### 8.3 Nice to Have
|
||||||
|
- ⭕ Admin override capability (with special permission and logging)
|
||||||
|
- ⭕ Amendment/revision workflow for approved PRs
|
||||||
|
- ⭕ Email notification when modification is attempted
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Related Requirements
|
||||||
|
|
||||||
|
### 9.1 From TOR
|
||||||
|
- **Section 2.1.5**: Multi-level approval workflow
|
||||||
|
- **Section 2.1.5**: Budget commitment on approval
|
||||||
|
- **Section 6.1**: Centralized Approval Workflow Engine
|
||||||
|
- **Section 6.1.4**: Approval history display
|
||||||
|
|
||||||
|
### 9.2 Dependencies
|
||||||
|
- Authentication & Authorization system
|
||||||
|
- Budget management system
|
||||||
|
- Audit logging infrastructure
|
||||||
|
- Centralized workflow engine (future enhancement)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Risk Assessment
|
||||||
|
|
||||||
|
### 10.1 Technical Risks
|
||||||
|
| Risk | Impact | Probability | Mitigation |
|
||||||
|
|------|--------|-------------|------------|
|
||||||
|
| Backend validation not enforced | High | Medium | Implement comprehensive unit tests and API tests |
|
||||||
|
| Frontend can be bypassed | High | Low | Backend is source of truth, frontend is UX only |
|
||||||
|
| Performance impact of audit logging | Medium | Low | Use async logging, optimize queries |
|
||||||
|
| Status transition edge cases | Medium | Medium | Comprehensive test coverage |
|
||||||
|
|
||||||
|
### 10.2 Business Risks
|
||||||
|
| Risk | Impact | Probability | Mitigation |
|
||||||
|
|------|--------|-------------|------------|
|
||||||
|
| Users cannot make legitimate corrections | High | Medium | Plan for amendment workflow in future phase |
|
||||||
|
| Approval process too rigid | Medium | Medium | Document escalation procedures |
|
||||||
|
| Training required for users | Low | High | Prepare user guides and FAQ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. Future Enhancements
|
||||||
|
|
||||||
|
### 11.1 Amendment Workflow ✅ **IMPLEMENTED** (2025-10-30)
|
||||||
|
For cases where approved PRs need corrections, the amendment workflow is now fully functional:
|
||||||
|
|
||||||
|
**Implementation Details**:
|
||||||
|
- **Entity**: `PurchaseRequisitionAmendment` - Tracks all amendment requests
|
||||||
|
- **Migration**: `20251029212550_AddPurchaseRequisitionAmendments.cs`
|
||||||
|
- **Service**: `PurchaseRequisitionAmendmentService` - Manages amendment lifecycle
|
||||||
|
- **DTOs**: `PurchaseRequisitionAmendmentDto`, `RequestAmendmentDto`, `ReviewAmendmentDto`
|
||||||
|
|
||||||
|
**API Endpoints**:
|
||||||
|
1. `POST /api/purchase-requisitions/{id}/request-amendment` - Request amendment for locked PR
|
||||||
|
2. `GET /api/purchase-requisitions/{id}/amendments` - Get all amendments for a PR
|
||||||
|
3. `GET /api/purchase-requisitions/amendments/pending` - Get pending amendments (for approvers)
|
||||||
|
4. `POST /api/purchase-requisitions/amendments/{amendmentId}/approve` - Approve amendment (unlocks PR)
|
||||||
|
5. `POST /api/purchase-requisitions/amendments/{amendmentId}/reject` - Reject amendment
|
||||||
|
|
||||||
|
**Workflow**:
|
||||||
|
1. User requests amendment with justification (creates amendment request with status `Pending`)
|
||||||
|
2. Amendment expires after 7 days if not reviewed
|
||||||
|
3. Approver can approve or reject the amendment
|
||||||
|
4. Upon approval, PR status changes back to `Draft` (temporarily unlocked)
|
||||||
|
5. User can edit and resubmit PR
|
||||||
|
6. After resubmission, PR goes through approval workflow again
|
||||||
|
7. Full audit trail maintained for all amendment actions
|
||||||
|
|
||||||
|
**Amendment Statuses**:
|
||||||
|
- `Pending`: Awaiting review
|
||||||
|
- `Approved`: Amendment approved, PR unlocked for editing
|
||||||
|
- `Rejected`: Amendment request rejected
|
||||||
|
- `Completed`: Amendment completed and PR resubmitted
|
||||||
|
- `Expired`: Amendment request expired without review (7 days)
|
||||||
|
|
||||||
|
**Security Features**:
|
||||||
|
- User context captured (user ID, username, IP address)
|
||||||
|
- Audit logging for all amendment actions
|
||||||
|
- Only one pending or approved amendment allowed per PR
|
||||||
|
- Draft PRs cannot request amendments (already editable)
|
||||||
|
- Expired amendments automatically marked
|
||||||
|
|
||||||
|
**Database Schema**:
|
||||||
|
```sql
|
||||||
|
purchase_requisition_amendments (
|
||||||
|
id UUID PRIMARY KEY,
|
||||||
|
purchase_requisition_id UUID NOT NULL,
|
||||||
|
requested_by_user_id VARCHAR(255),
|
||||||
|
requested_by_user_name VARCHAR(255),
|
||||||
|
requested_at_utc TIMESTAMP,
|
||||||
|
justification VARCHAR(2000),
|
||||||
|
status VARCHAR(50), -- Pending/Approved/Rejected/Completed/Expired
|
||||||
|
reviewed_by_user_id VARCHAR(255),
|
||||||
|
reviewed_by_user_name VARCHAR(255),
|
||||||
|
reviewed_at_utc TIMESTAMP,
|
||||||
|
review_remarks VARCHAR(2000),
|
||||||
|
original_status VARCHAR(50),
|
||||||
|
requested_from_ip_address VARCHAR(45),
|
||||||
|
reviewed_from_ip_address VARCHAR(45),
|
||||||
|
expires_at_utc TIMESTAMP
|
||||||
|
)
|
||||||
|
```
|
||||||
|
|
||||||
|
**Example Usage**:
|
||||||
|
```bash
|
||||||
|
# Request amendment
|
||||||
|
curl -X POST "http://localhost:5200/api/purchase-requisitions/{pr-id}/request-amendment" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d '{"justification": "Need to correct quantity from 10 to 15 units"}'
|
||||||
|
|
||||||
|
# Get pending amendments (for approvers)
|
||||||
|
curl "http://localhost:5200/api/purchase-requisitions/amendments/pending"
|
||||||
|
|
||||||
|
# Approve amendment
|
||||||
|
curl -X POST "http://localhost:5200/api/purchase-requisitions/amendments/{amendment-id}/approve" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d '{"reviewRemarks": "Approved. Please make necessary corrections."}'
|
||||||
|
```
|
||||||
|
|
||||||
|
### 11.2 Integration with Workflow Engine
|
||||||
|
When the Centralized Approval Workflow Engine (Section 6.1 of TOR) is implemented:
|
||||||
|
- Replace manual approval with workflow-driven approval
|
||||||
|
- Support multi-level approval chains
|
||||||
|
- Implement delegation and escalation
|
||||||
|
- Add approval history visualization
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 12. References
|
||||||
|
|
||||||
|
### 12.1 Documents
|
||||||
|
- TOR Document: `/docs/references/tor.md`
|
||||||
|
- Current Implementation: `/piam-web/src/app/features/procurement/components/purchase-requisition-form/`
|
||||||
|
- Backend API: (To be documented)
|
||||||
|
|
||||||
|
### 12.2 Standards
|
||||||
|
- HTTP Status Codes: RFC 7231
|
||||||
|
- Audit Logging: OWASP Logging Cheat Sheet
|
||||||
|
- Error Handling: REST API Best Practices
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Document Revision History
|
||||||
|
|
||||||
|
| Version | Date | Author | Changes |
|
||||||
|
|---------|------|--------|---------|
|
||||||
|
| 1.0 | 2025-10-30 | Claude Code | Initial requirement documentation |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**End of Document**
|
||||||
53
references/gap-analysis-module-2-todo.md
Normal file
53
references/gap-analysis-module-2-todo.md
Normal file
@@ -0,0 +1,53 @@
|
|||||||
|
# Module 2 Remediation TODOs
|
||||||
|
|
||||||
|
Action items derived from `docs/references/gap-analysis-module-2.md`. Track each task until the requirement transitions to ✅ in the gap analysis.
|
||||||
|
|
||||||
|
## 2.1 Purchase Requisition
|
||||||
|
- [x] Extend PR DTOs/entities/UI to capture supplier, VAT type, procurement method, company code, contract number (`piam-api` PR DTOs & `piam-web` form).
|
||||||
|
- [x] Surface last purchase price, stock on hand, and packaging units in the PR item picker (`piam-web` procurement form + item services).
|
||||||
|
- [x] Remove automatic approve-on-submit flow; route submissions to workflow reviewers only (`piam-web` purchase-requisition form logic).
|
||||||
|
- [x] Add PR search filters for company/vendor and expose those columns in the workspace list.
|
||||||
|
- [x] Support manual PR numbering and contract metadata persistence (`piam-api` domain + repository).
|
||||||
|
- [x] Enforce editable-price permissions, automated vendor pricing guardrails, and inventory threshold controls.
|
||||||
|
|
||||||
|
## 2.2 Request for Quotation
|
||||||
|
- [x] Block supplier bids submitted after `submissionDeadlineUtc` in portal services (`SupplierPortalService`).
|
||||||
|
- [x] Deliver side-by-side bid comparison UI with automatic best-price highlighting (`piam-web` RFQ detail component).
|
||||||
|
|
||||||
|
## 2.3 Purchase Orders
|
||||||
|
- [x] Introduce VAT type/department fields in PO header DTOs and Angular form.
|
||||||
|
- [x] Add VAT modes (gross/net toggles) and per-line tax splits to item grid (`PurchaseOrderItemDto` + UI).
|
||||||
|
- [x] Implement manual/templated PO numbering and VAT schema configuration (`PurchaseOrderRepository` + UI).
|
||||||
|
- [x] Add support for multi-schedule milestones, freebies, discounts, and per-line tax calculations (PO domain model & UI).
|
||||||
|
- [x] Require explicit approval workflow steps in the UI instead of auto-submit, and implement spend-based controls/gates (`purchase-order-form` component + approval routing).
|
||||||
|
- [x] Provide PDF/email distribution workflows and e-signature capture for approved POs.
|
||||||
|
- [x] Persist change-order history and expose PO revision logs (revision tracking and document versioning).
|
||||||
|
- [x] Enhance PO inquiries with PO-type filters and due-date alerting.
|
||||||
|
- [x] Create financial postings (AP, GL, withholding tax, deposit tracking) and attachment storage for PO documents.
|
||||||
|
|
||||||
|
## 2.4 Goods Receipt Note
|
||||||
|
- [x] Build real procurement UI for GRN drafts tied to backend services (replace placeholder component in `procurement-goods-receipts.component`).
|
||||||
|
- [x] Allow non-PO receiving paths and add receiving warehouse/delivery note fields (header capture).
|
||||||
|
- [x] Capture packaging conversions, freebies, discounts, and VAT values per received item (item grid enhancements).
|
||||||
|
- [x] Add role-based permissions/audit logging for GRN operations (beyond generic API authorization).
|
||||||
|
- [x] Support direct-to-department receipts that bypass inventory storage.
|
||||||
|
- [x] Provide GRN print/export endpoints and barcode label generation.
|
||||||
|
- [x] Persist and calculate receipt-level VAT/discount totals (financial calculations on GRN).
|
||||||
|
|
||||||
|
## 2.5 Return to Supplier
|
||||||
|
- [x] Implement complete return-to-supplier backend workflow (API, repository, domain models).
|
||||||
|
- [x] Replace mock UI data in `return-to-supplier-workspace.component` with live integrations.
|
||||||
|
|
||||||
|
## 2.6 Procurement Documents & Reports
|
||||||
|
- [ ] Deliver canned PR/PO/GRN reports with PDF/Excel export in the procurement workspace.
|
||||||
|
- [ ] Surface module-specific procurement dashboards (not just generic analytics) summarizing pipeline by method/status as described in the spec.
|
||||||
|
- [ ] Create dedicated UI to slice and filter procurement results by procurement method in real-time.
|
||||||
|
|
||||||
|
## 2.7 Integrations & Automation
|
||||||
|
- [ ] Integrate procurement events with GL and asset capitalization modules for financial postings.
|
||||||
|
- [ ] Provide cross-module audit workspace consolidating budget, procurement, accounting, and inventory data.
|
||||||
|
|
||||||
|
## 2.8 Additional Features
|
||||||
|
- [ ] Add configurable reorder points/alerts and UI around AI requisition suggestions.
|
||||||
|
- [ ] Enrich PO data with VAT breakdowns, deposits, guarantees, and discount aggregates.
|
||||||
|
- [ ] Capture procurement timeline metadata (submission deadlines, officials, automatic workday calendars, and payment scheduling) with holiday-aware calculations.
|
||||||
84
references/gap-analysis-module-2.md
Normal file
84
references/gap-analysis-module-2.md
Normal file
@@ -0,0 +1,84 @@
|
|||||||
|
# Module 2 Gap Analysis
|
||||||
|
|
||||||
|
Comparison of the live implementation (`piam-api/`, `piam-web/`) against the procurement requirements captured in `docs/references/module2.text`. Status legend: ✅ Implemented, ⚠️ Partial, ❌ Missing.
|
||||||
|
|
||||||
|
## 2.1 Purchase Requisition (PR)
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.1.1 Standard PR header and supplier data | ⚠️ Partial | Draft/submit lifecycle is implemented (`piam-api/src/PiamMasterData.Api/Controllers/PurchaseRequisitionsController.cs:18`), but both the DTO and UI only capture title, department, requester, budget, and dates—no supplier, VAT type, procurement method, contract number, or company code as required (`piam-api/src/PiamMasterData.Application/DTOs/CreatePurchaseRequisitionDto.cs:7`; `piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.html:55`). |
|
||||||
|
| 2.1.2 Budget linkage & visibility | ✅ | Budget code is mandatory and budget snapshots/commitments are enforced during submit (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:341`), with the form surfacing available-to-commit balances (`piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.html:100`). |
|
||||||
|
| 2.1.3 Item selection insights | ⚠️ Partial | Item search, unit selection, and quantity capture exist, but there is no UI/API for last purchase price or on-hand stock visibility, nor packaging-unit handling (`piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.html:145`; `piam-api/src/PiamMasterData.Application/DTOs/PurchaseRequisitionLineUpsertDto.cs:7`). |
|
||||||
|
| 2.1.4 Real-time budget check & commitment | ✅ | Submission verifies encumbrance headroom and creates/updates active commitments atomically (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:341`). |
|
||||||
|
| 2.1.5 Approval workflow | ⚠️ Partial | Workflow engine supports multi-step approvals (`piam-api/src/PiamMasterData.Infrastructure/Services/ApprovalWorkflowEngine.cs:51`), yet the Angular form auto-approves immediately after submission, bypassing segregation of duties (`piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.ts:268`). |
|
||||||
|
| 2.1.6 PR search & tracking | ⚠️ Partial | Listing API handles keyword, status, department, budget, and dates (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:17`), but there is no support for company/vendor filters or listing company codes requested in the spec. |
|
||||||
|
| 2.1.7 Document numbering & authoring | ⚠️ Partial | Automatic sequencing is present (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:711`) and submission comments are stored, but manual number overrides and contract metadata are absent from the model (`piam-api/src/PiamMasterData.Domain/Entities/PurchaseRequisition.cs:7`). |
|
||||||
|
| 2.1.8 Additional controls (lead time, price governance) | ⚠️ Partial | Required-by date is supported (`piam-web/src/app/features/procurement/components/purchase-requisition-form/purchase-requisition-form.component.html:92`), yet there is no enforcement around editable price permissions, automatic vendor price suggestion, or inventory thresholds. |
|
||||||
|
|
||||||
|
## 2.2 Request for Quotation (RFQ)
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.2.1 Create RFQ from approved PR lines | ✅ | RFQ endpoints build from eligible requisition lines and maintain linkages (`piam-api/src/PiamMasterData.Api/Controllers/RfqsController.cs:31`; `piam-api/src/PiamMasterData.Infrastructure/Repositories/RfqRepository.cs:38`). |
|
||||||
|
| 2.2.2 Invite qualified suppliers | ✅ | Supplier lookup/invite flows and committee validation exist, including portal onboarding (`piam-api/src/PiamMasterData.Api/Controllers/RfqsController.cs:86`; `piam-api/src/PiamMasterData.Api/Controllers/SupplierPortalController.cs:19`). |
|
||||||
|
| 2.2.3 Supplier portal submissions & deadline control | ⚠️ Partial | Portal authentication and bid submission are implemented (`piam-api/src/PiamMasterData.Application/Services/SupplierPortalService.cs:177`), but there is no guard against bids submitted after `submissionDeadlineUtc`, so late submissions are not blocked as the requirement demands (`piam-api/src/PiamMasterData.Application/Services/SupplierPortalService.cs:200`). |
|
||||||
|
| 2.2.4 Bid comparison screen | ⚠️ Partial | RFQ detail page lists bids and allows award selection, yet there is no side-by-side comparison or automatic “best price” highlighting per line (`piam-web/src/app/features/procurement/components/rfq-detail/rfq-detail.component.html:248`). |
|
||||||
|
| 2.2.5 Auto-create PO/contract from winners | ✅ | Award endpoint transitions RFQ lines and downstream `CreatePurchaseOrderFromRequisitionsDto` consumes awarded requisition lines (`piam-api/src/PiamMasterData.Infrastructure/Repositories/RfqRepository.cs:193`; `piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseOrderRepository.cs:183`). |
|
||||||
|
|
||||||
|
## 2.3 Purchase Orders (PO)
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.3.1 Build PO from approved PRs | ✅ | Workbench and creation path assemble PO items from approved requisition lines (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseOrderRepository.cs:23`; `piam-web/src/app/features/procurement/components/purchase-order-workbench`). |
|
||||||
|
| 2.3.2 Header fields (supplier, VAT type, department) | ⚠️ Partial | Supplier selection, payment terms, delivery dates, project metadata, and procurement method exist (`piam-web/src/app/features/procurement/components/purchase-order-form/purchase-order-form.component.ts:27`), but VAT type and purchasing department fields are absent. |
|
||||||
|
| 2.3.3 Item grid with VAT calculations | ⚠️ Partial | Quantities and unit price editing are present (`piam-web/src/app/features/procurement/components/purchase-order-form/purchase-order-form.component.html:166`), yet neither the API nor UI handle VAT modes, gross/net toggles, freebies, or per-line tax splits (`piam-api/src/PiamMasterData.Application/DTOs/PurchaseOrderItemDto.cs:3`). |
|
||||||
|
| 2.3.4 Numbering & VAT schema | ❌ | Only auto-incremented `PO-<year>-####` numbers exist (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseOrderRepository.cs:320`); there is no manual numbering option or VAT scheme configuration. |
|
||||||
|
| 2.3.5 Special PO structures (milestones/freebies/versioning) | ❌ | No support for multi-tranche scheduling, free goods, document versioning, or cost/discount allocation is present in domain models (`piam-api/src/PiamMasterData.Domain/Entities/PurchaseOrderItem.cs:5`). |
|
||||||
|
| 2.3.6 Approval workflow & spend gates | ⚠️ Partial | Submission triggers the central workflow engine (`piam-api/src/PiamMasterData.Application/Services/PurchaseOrderService.cs:28`), but the UI auto-submits without presenting approval routing or spend-based controls (`piam-web/src/app/features/procurement/components/purchase-order-form/purchase-order-form.component.ts:260`). |
|
||||||
|
| 2.3.7 Distribution & e-signatures | ❌ | Controllers expose CRUD only; no API or UI exists to render PDFs, email suppliers, or capture electronic signatures (`piam-api/src/PiamMasterData.Api/Controllers/PurchaseOrdersController.cs:19`). |
|
||||||
|
| 2.3.8 Change tracking & audit | ❌ | There is no change-order log or revision history persisted for POs (`piam-api/src/PiamMasterData.Domain/Entities/PurchaseOrder.cs:5`). |
|
||||||
|
| 2.3.9 PO inquiry & alerts | ⚠️ Partial | List endpoint supports supplier/date/status filters (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseOrderRepository.cs:237`), but there is no PO type filter nor due-date alerting. |
|
||||||
|
| 2.3.10 Financial postings & attachments | ❌ | Automatic AP/GL postings, withholding tax capture, billing intake, and PO file attachments are not implemented; models only store simple notes (`piam-api/src/PiamMasterData.Application/DTOs/PurchaseOrderDetailDto.cs:15`). |
|
||||||
|
|
||||||
|
## 2.4 Goods Receipt Note (GRN)
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.4.1 Initiate receiving (PO & non-PO) | ⚠️ Partial | Back-end workbench filters approved/partial POs and supports partial receipts (`piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:23`), but there is no path for non-PO receipts and the procurement UI is placeholder data only (`piam-web/src/app/features/procurement/components/procurement-goods-receipts/procurement-goods-receipts.component.ts:20`). |
|
||||||
|
| 2.4.2 PO data pull | ✅ | Selecting a PO hydrates supplier and line items (`piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:89`). |
|
||||||
|
| 2.4.3 Header capture (invoice, warehouse, delivery note) | ⚠️ Partial | Supplier invoice number/date fields exist (`piam-api/src/PiamMasterData.Application/DTOs/GoodsReceiptNoteDetailDto.cs:7`), but there is no field for receiving warehouse or delivery note metadata. |
|
||||||
|
| 2.4.4 Item grid (freebies, packaging) | ❌ | Only quantity-to-receive is tracked; there is no representation of packaging conversions or free-goods tracking (`piam-api/src/PiamMasterData.Application/DTOs/GoodsReceiptNoteItemDto.cs:7`). |
|
||||||
|
| 2.4.5 Lot/serial enforcement | ✅ | Lot/serial requirements and validation paths are fully implemented, including expiry enforcement (`piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:328`). |
|
||||||
|
| 2.4.6 Put-away suggestions | ✅ | Default bin resolution and assignment occur during draft creation and posting (`piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:165`). |
|
||||||
|
| 2.4.7 Quality inspection flow | ✅ | Posting creates quarantine tasks for inspected items (`piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:465`). |
|
||||||
|
| 2.4.8 Inventory, PO status, AP trigger | ✅ | Posting moves inventory, updates PO status, and creates pending AP invoices (`piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:487`). |
|
||||||
|
| 2.4.9 Permissions & audit | ❌ | No role-based guardrails or audit trail specific to GRN operations exist beyond generic API authorization; procurement UI lacks status inspection tooling (`piam-web/src/app/features/procurement/components/procurement-goods-receipts/procurement-goods-receipts.component.ts:65`). |
|
||||||
|
| 2.4.10 Direct-to-department receiving | ❌ | There is no option to post receipts directly as departmental issues; all receipts flow into inventory (`piam-api/src/PiamMasterData.Application/DTOs/GoodsReceiptNoteItemDto.cs:7`). |
|
||||||
|
| 2.4.11 Output documents & barcode | ❌ | No GRN printing/export endpoints or barcode generation after posting are present. |
|
||||||
|
| 2.4.12 Discounts/VAT on receipt | ❌ | GRN items do not carry VAT/discount or total-value fields, so financial adjustments per receipt are unsupported (`piam-api/src/PiamMasterData.Application/DTOs/GoodsReceiptNoteItemDto.cs:7`). |
|
||||||
|
|
||||||
|
## 2.5 Return to Supplier
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.5.x Return order lifecycle | ❌ | There is no API, repository, or domain workflow for return-to-supplier; the Angular view is mock data with TODO comments (`piam-web/src/app/features/procurement/components/return-to-supplier-workspace/return-to-supplier-workspace.component.ts:20`). |
|
||||||
|
|
||||||
|
## 2.6 Procurement Documents & Reports
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.6.1 Document template builder | ✅ | Template CRUD and editor UI exist for PO/RFQ printouts (`piam-api/src/PiamMasterData.Api/Controllers/PrintTemplatesController.cs:18`; `piam-web/src/app/features/print-templates/components`). |
|
||||||
|
| 2.6.2 Standard reporting | ⚠️ Partial | Analytics services and dashboards are present (`piam-api/src/PiamMasterData.Api/Controllers/AnalyticsController.cs:9`), but specific PR/PO/GRN canned reports and Excel/PDF exports referenced in the TOR are not surfaced in the procurement area. |
|
||||||
|
| 2.6.3 End-to-end procurement overview | ⚠️ Partial | Procurement dashboard DTOs provide KPIs (`piam-api/src/PiamMasterData.Application/DTOs/ProcurementDashboardDtos.cs`), yet the procurement UI only links to generic analytics without module-specific summaries (`piam-web/src/app/features/procurement/components/procurement-reports-hub/procurement-reports-hub.component.ts:21`). |
|
||||||
|
| 2.6.4 Real-time summaries by procurement method | ⚠️ Partial | Dashboard APIs can filter by status/method, but no dedicated UI exists to slice results by procurement method as described. |
|
||||||
|
|
||||||
|
## 2.7 Integrations & Automation
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.7.1 System integrations (GL/AP/Inventory/Assets) | ⚠️ Partial | Budget commitments and AP pending invoices are wired (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:341`; `piam-api/src/PiamMasterData.Infrastructure/Repositories/GoodsReceiptRepository.cs:501`), but there is no integration with GL or asset capitalization workflows. |
|
||||||
|
| 2.7.2 Cross-department data consolidation | ⚠️ Partial | APIs expose procurement data via REST, yet there is no unified data mart or cross-module audit workspace per requirement. |
|
||||||
|
| 2.7.3 Workflow configurability | ✅ | Central workflow admin and execution services meet the configurable approval requirement (`piam-api/src/PiamMasterData.Api/Controllers/ApprovalWorkflowAdminController.cs`; `piam-api/src/PiamMasterData.Infrastructure/Services/ApprovalWorkflowEngine.cs:51`). |
|
||||||
|
|
||||||
|
## 2.8 Additional Procurement Features
|
||||||
|
| Requirement | Status | Key observations |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 2.8.1 Reorder planning & auto PO | ⚠️ Partial | AI-driven requisition suggestions are implemented (`piam-api/src/PiamMasterData.Infrastructure/Repositories/PurchaseRequisitionRepository.cs:585`), but there is no configurable reorder point or alert UI. |
|
||||||
|
| 2.8.2 Multi-device support | ✅ | Angular front-end is responsive and built for desktop/tablet/mobile form factors. |
|
||||||
|
| 2.8.3 Committee management | ✅ | Committee maintenance and PO committee linkage are complete (`piam-api/src/PiamMasterData.Api/Controllers/CommitteesController.cs`; `piam-web/src/app/features/procurement/components/purchase-order-form/purchase-order-form.component.html:202`). |
|
||||||
|
| 2.8.4 Budgetary fields (VAT, deposits, guarantees) | ❌ | PO models lack VAT breakdowns, deposits, guarantees, or discount aggregates (`piam-api/src/PiamMasterData.Application/DTOs/PurchaseOrderDetailDto.cs:15`). |
|
||||||
|
| 2.8.5 Special procurement conditions & timeline fields | ⚠️ Partial | PO captures TOR reference and shipping dates, but fields for submission deadlines, officials, automatic workday calendars, and payment scheduling are absent (`piam-web/src/app/features/procurement/components/purchase-order-form/purchase-order-form.component.html:131`). |
|
||||||
|
|
||||||
309
references/module2.text
Normal file
309
references/module2.text
Normal file
@@ -0,0 +1,309 @@
|
|||||||
|
โมดูล 2: การจัดซื้อจัดจ้าง (Procurement Management)
|
||||||
|
2.1 การจัดการใบขอซื้อ (Purchase Requisition - PR)
|
||||||
|
ระบบรองรับกระบวนการขอซื้อที่เป็นมาตรฐาน ควบคุมการใช้งบประมาณตั้งแต่จุดเริ่มต้น โดยมีคุณสมบัติอย่างน้อยดังต่อไปนี้:
|
||||||
|
2.1.1 การสร้างและจัดการใบขอซื้อ
|
||||||
|
ระบบสามารถสร้างการขอซื้อโดยการคีย์ข้อมูลขอซื้อ
|
||||||
|
สามารถบันทึกข้อมูลการเสนอซื้อโดยมีข้อมูล:
|
||||||
|
ผู้จำหน่าย
|
||||||
|
ประเภทใบเสนอซื้อ
|
||||||
|
แผนกที่เสนอซื้อ
|
||||||
|
ประเภท VAT
|
||||||
|
วิธีการจัดซื้อจัดจ้าง
|
||||||
|
วันที่เสนอซื้อ
|
||||||
|
สามารถระบุหัวเรื่องในการขอเสนอซื้อสินค้าได้
|
||||||
|
สามารถระบุรหัสบริษัทที่จะขอเสนอซื้อได้
|
||||||
|
สามารถระบุเลขที่สัญญาและหมายเหตุที่เกี่ยวข้องในการจัดซื้อได้
|
||||||
|
2.1.2 การเชื่อมโยงงบประมาณ
|
||||||
|
ต้องเชื่อมโยงกับโครงการที่ได้รับอนุมัติจากโมดูลงบประมาณ (Required)
|
||||||
|
ระบบแสดงงบประมาณคงเหลือของโครงการนั้นให้ผู้ใช้ทราบ
|
||||||
|
สามารถเชื่อมโยงกับระบบงบประมาณ เมื่อมีการขอซื้อ/จ้าง ระบบสามารถตรวจสอบงบประมาณคงเหลือและรายงานจำนวนคงเหลือได้
|
||||||
|
ระบบสามารถรองรับการตรวจสอบงบประมาณกับการขอซื้อ
|
||||||
|
สามารถบันทึกงบประมาณในการจัดซื้อได้
|
||||||
|
2.1.3 การเลือกและเพิ่มรายการพัสดุ
|
||||||
|
ผู้ใช้สามารถค้นหาและเพิ่มรายการพัสดุ/ครุภัณฑ์ที่ต้องการ พร้อมระบุจำนวน
|
||||||
|
ระบบแสดงราคาซื้อครั้งล่าสุดเพื่อให้ผู้ใช้ประเมินราคารวมของใบขอซื้อได้
|
||||||
|
สามารถระบุจำนวนสินค้าที่จะจัดซื้อเป็นหน่วยนับและหน่วยบรรจุได้
|
||||||
|
สามารถแสดงจำนวนสินค้าคงเหลือ
|
||||||
|
2.1.4 การตรวจสอบและกันงบประมาณ ก่อนส่งอนุมัติ ระบบดำเนินการดังนี้:
|
||||||
|
การตรวจสอบงบประมาณ (Real-time Budget Check): ตรวจสอบยอดรวมของ PR กับงบประมาณคงเหลือ
|
||||||
|
การกันงบประมาณ (Budget Commitment): หากงบประมาณเพียงพอ ระบบจะทำการ "กันงบประมาณ" ในโมดูลงบประมาณโดยอัตโนมัติ
|
||||||
|
การส่งเข้าระบบอนุมัติ: สถานะของ PR จะเปลี่ยนเป็น "รออนุมัติ" และถูกส่งต่อไปยังผู้อนุมัติตาม Workflow ที่กำหนด
|
||||||
|
2.1.5 ระบบอนุมัติ
|
||||||
|
ระบบสามารถรองรับกระบวนการอนุมัติการขอซื้อได้หลายระดับและหลายเงื่อนไข
|
||||||
|
มีระบบการอนุมัติใบเสนอซื้อเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากได้รับการอนุมัติให้ทำเรื่องเสนอซื้อ
|
||||||
|
สามารถกำหนดวงเงินอนุมัติการขอซื้อ/จ้างสำหรับผู้มีอำนาจอนุมัติในแต่ละระดับได้
|
||||||
|
รองรับการจัดทำ/ยกเลิก ใบขอซื้อ/จ้าง ได้
|
||||||
|
เชื่อมโยงกับระบบอนุมัติกลาง (Centralized Approval Workflow Engine)
|
||||||
|
2.1.6 การค้นหาและแสดงผล
|
||||||
|
สามารถค้นหาข้อมูลรายการใบเสนอซื้อย้อนหลังโดยค้นหาได้จาก:
|
||||||
|
ผู้จำหน่าย
|
||||||
|
เลขที่ใบเสนอซื้อ
|
||||||
|
ประเภทใบเสนอซื้อ
|
||||||
|
สถานะเอกสาร
|
||||||
|
หน่วยขอซื้อ
|
||||||
|
วันที่เสนอซื้อ
|
||||||
|
สามารถค้นหาข้อมูลรายการใบขอซื้อย้อนหลังโดยค้นหาได้จาก:
|
||||||
|
เลขที่ใบขอซื้อ
|
||||||
|
หน่วยงานที่ขอซื้อ
|
||||||
|
บริษัทที่ขอซื้อ
|
||||||
|
วันที่ขอซื้อ
|
||||||
|
แสดงรายการ PR ที่สร้างโดยแผนกของผู้ใช้งาน โดยมีคอลัมน์:
|
||||||
|
เลขที่ใบขอซื้อ
|
||||||
|
วันที่ขอ
|
||||||
|
โครงการ/รหัสงบประมาณ
|
||||||
|
ยอดรวมโดยประมาณ
|
||||||
|
สถานะ (เช่น "ฉบับร่าง", "รออนุมัติ", "อนุมัติแล้ว", "ปฏิเสธ", "สร้าง PO แล้ว")
|
||||||
|
2.1.7 การจัดการเอกสาร
|
||||||
|
สามารถกำหนดเลขที่ใบขอซื้อ/จ้าง ได้ทั้งแบบ Manual และแบบอัตโนมัติ
|
||||||
|
สามารถแยกเลขที่ใบขอซื้อให้อัตโนมัติ
|
||||||
|
สามารถจัดเก็บข้อมูลผู้จัดทำใบสั่งซื้อ/สั่งจ้าง รวมถึงรายละเอียดต่างๆ ได้ เช่น รหัส ชื่อ วันที่
|
||||||
|
รองรับการบันทึกข้อความเพิ่มเติม (Comment) ของการขอซื้อ เพื่อแสดงไปยังผู้ขายและใบสั่งซื้อ
|
||||||
|
2.1.8 คุณสมบัติเพิ่มเติม
|
||||||
|
สามารถระบุจำนวนวันที่ต้องส่งมอบสินค้าได้
|
||||||
|
ระบบสามารถแสดงรายละเอียดราคาและผู้ขายของสินค้าที่ขอซื้อโดยอัตโนมัติตามเงื่อนไขที่กำหนดในสินค้า
|
||||||
|
ระบบสามารถกำหนดสิทธิ์ในการแก้ไขราคา การยกเลิกเปลี่ยนแปลงของใบขอซื้อ
|
||||||
|
ระบบสามารถรองรับการตรวจสอบสถานะของการขอสั่งซื้อ
|
||||||
|
|
||||||
|
2.2 การบริหารจัดการใบเสนอราคา (Request for Quotation - RFQ)
|
||||||
|
ระบบรองรับกระบวนการจัดหาเชิงกลยุทธ์ผ่านการเปรียบเทียบราคาและคัดเลือกผู้ขายได้อย่างมีประสิทธิภาพและโปร่งใส โดยมีคุณสมบัติอย่างน้อยดังต่อไปนี้:
|
||||||
|
2.2.1 การสร้างและจัดการ RFQ
|
||||||
|
สามารถเริ่มต้นสร้าง RFQ ได้จาก "ใบขอซื้อ (PR)" ที่ผ่านการอนุมัติแล้ว
|
||||||
|
สามารถรวมหลายรายการจากหลายใบขอซื้อเพื่อจัดทำ RFQ ฉบับเดียวได้
|
||||||
|
เจ้าหน้าที่จัดซื้อสามารถสร้างเอกสาร RFQ ในระบบ โดยระบุรายละเอียด:
|
||||||
|
สินค้า/บริการ
|
||||||
|
คุณสมบัติทางเทคนิค (Specification)
|
||||||
|
จำนวนที่ต้องการ
|
||||||
|
กำหนดวันสิ้นสุดการยื่นข้อเสนอ
|
||||||
|
ระบบสามารถรองรับกระบวนการขอใบเสนอราคา (Request for Quotes)
|
||||||
|
2.2.2 การเชิญผู้ขาย
|
||||||
|
สามารถค้นหาและเลือกผู้ขายที่ผ่านการรับรอง (Qualified Supplier) จากทะเบียนผู้ขาย
|
||||||
|
สามารถส่งคำเชิญให้เข้าร่วมยื่นข้อเสนอผ่านทาง "Supplier Portal"
|
||||||
|
สามารถกำหนดวิธีการส่งใบสั่งซื้อให้ผู้ขาย เช่น Fax, Email, EDX
|
||||||
|
2.2.3 การยื่นข้อเสนอผ่าน Supplier Portal
|
||||||
|
ผู้ขายที่ได้รับเชิญทำการยื่นข้อเสนอ (ราคา, เงื่อนไข, ระยะเวลาจัดส่ง) ผ่านทาง Supplier Portal
|
||||||
|
ระบบป้องกันการยื่นข้อเสนอหลังสิ้นสุดเวลาที่กำหนด
|
||||||
|
ผู้ขายสามารถดู RFQ ที่ได้รับเชิญและยื่นข้อเสนอผ่านระบบได้
|
||||||
|
2.2.4 การเปรียบเทียบข้อเสนอ
|
||||||
|
หลังจากสิ้นสุดเวลายื่นข้อเสนอ ระบบมี "หน้าจอเปรียบเทียบข้อเสนอ (Bid Comparison Screen)"
|
||||||
|
แสดงข้อมูลจากผู้ขายทุกรายแบบเคียงข้างกัน (Side-by-side)
|
||||||
|
มีการเน้น (Highlight) ข้อเสนอที่ดีที่สุดในแต่ละรายการ
|
||||||
|
ช่วยในการวิเคราะห์และตัดสินใจได้ง่าย
|
||||||
|
2.2.5 การอนุมัติและสร้างเอกสาร
|
||||||
|
หลังจากคัดเลือกผู้ชนะแล้ว ระบบสามารถสร้าง "ใบสั่งซื้อ (PO)" หรือ "สัญญา (Contract)" จากข้อมูลของผู้ชนะใน RFQ ได้โดยอัตโนมัติ
|
||||||
|
|
||||||
|
2.3 การจัดการใบสั่งซื้อ (Purchase Order - PO)
|
||||||
|
ระบบรองรับการสร้างเอกสารสั่งซื้อที่เป็นทางการ มีการอ้างอิงที่ถูกต้อง และส่งมอบให้ผู้ขายได้อย่างมีประสิทธิภาพ โดยมีคุณสมบัติอย่างน้อยดังต่อไปนี้:
|
||||||
|
2.3.1 การสร้างใบสั่งซื้อ
|
||||||
|
สามารถสร้างใบสั่งซื้อจากใบขอซื้อ (PR) ที่อนุมัติแล้ว
|
||||||
|
สามารถเลือกรายการจากหลาย PR (หากเป็นผู้ขายรายเดียวกัน) เพื่อรวมสร้างเป็น PO ฉบับเดียวได้
|
||||||
|
ระบบสามารถสร้างการสั่งซื้อโดยการคีย์ข้อมูลสั่งซื้อ
|
||||||
|
ระบบสามารถสร้างการสั่งซื้อให้อัตโนมัติโดยการดึงข้อมูลจากข้อมูลการขอซื้อ
|
||||||
|
สามารถบันทึกออกใบสั่งซื้อครุภัณฑ์โดยเลือกจากใบขอซื้อที่ได้รับการอนุมัติ ซึ่งข้อมูลที่อยู่ในใบขอซื้อจะเชื่อมโยงมายังใบสั่งซื้อที่ออก
|
||||||
|
2.3.2 ข้อมูลส่วนหัว (Header)
|
||||||
|
การเลือกผู้ขาย (Required): ต้องมีช่องสำหรับค้นหาและเลือกผู้ขายจากทะเบียน
|
||||||
|
เงื่อนไข (Terms): ระบุ
|
||||||
|
เงื่อนไขการชำระเงิน (Payment Terms)
|
||||||
|
วิธีการจัดส่ง
|
||||||
|
ประเภท VAT
|
||||||
|
แผนกที่สั่งซื้อ
|
||||||
|
วันที่สั่งซื้อ
|
||||||
|
2.3.3 รายการสินค้า (Item Grid)
|
||||||
|
เจ้าหน้าที่จัดซื้อกรอกราคาต่อหน่วย (Unit Price) ตามที่ตกลงกับผู้ขาย
|
||||||
|
ระบบคำนวณยอดรวมและภาษีมูลค่าเพิ่ม (VAT) ให้อัตโนมัติ
|
||||||
|
สามารถคำนวณหรือบันทึกมูลค่าภาษีได้ ทั้งแบบรวมภาษีและไม่รวมภาษี
|
||||||
|
สามารถระบุจำนวนเงินราคาสินค้าที่จะจัดซื้อรวมของแต่ละรายการสินค้า
|
||||||
|
2.3.4 การกำหนดรูปแบบและหมายเลข
|
||||||
|
สามารถกำหนดเลขที่ใบสั่งซื้อ/สั่งจ้างได้โดยอัตโนมัติหรือแบบ Manual
|
||||||
|
กรณีกำหนดเลขที่เอกสารโดยอัตโนมัติ สามารถกำหนดได้ทั้งตัวเลขและตัวอักษร แยกตามประเภทสินค้า
|
||||||
|
สามารถกำหนดรูปแบบการสั่งซื้อรองรับเรื่องภาษีมูลค่าเพิ่มได้ทั้ง VATIN, VATOUT หรือ Exemption (ไม่มี VAT)
|
||||||
|
2.3.5 การรองรับรูปแบบการสั่งซื้อพิเศษ
|
||||||
|
สามารถรองรับการบันทึกใบสั่งซื้อสั่งจ้างหลายๆ งวดได้
|
||||||
|
ระบบสามารถรองรับการสั่งซื้อแบบมีของแถม
|
||||||
|
รองรับการบริหารจัดการเวอร์ชั่น (Version) ของเอกสารใบเสนอราคา/สั่งซื้อ/จัดจ้าง
|
||||||
|
สามารถรองรับการปันส่วนค่าธรรมเนียม ค่าใช้จ่าย ส่วนลด
|
||||||
|
สามารถรองรับการคำนวณภาษีมูลค่าเพิ่มเมื่อสั่งซื้อ
|
||||||
|
2.3.6 ระบบอนุมัติ
|
||||||
|
ใบสั่งซื้อจะต้องผ่านกระบวนการอนุมัติภายในฝ่าย (ตามวงเงินและประเภท)
|
||||||
|
ผ่านทางระบบอนุมัติกลาง ก่อนจึงจะสามารถส่งให้ผู้ขายได้
|
||||||
|
มีระบบการอนุมัติใบสั่งซื้อเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากได้รับการอนุมัติให้ทำเรื่องสั่งซื้อ
|
||||||
|
ระบบสามารถรองรับกระบวนการอนุมัติการสั่งซื้อ
|
||||||
|
สามารถกำหนดเงื่อนไขของการสร้างใบสั่งซื้อแบบอัตโนมัติได้
|
||||||
|
ระบบสามารถกำหนดสิทธิในการสั่งซื้อได้หลายระดับและหลายเงื่อนไข
|
||||||
|
2.3.7 การส่งเอกสารและการจัดการ
|
||||||
|
เมื่อ PO ได้รับการอนุมัติขั้นสุดท้าย ระบบจะเปลี่ยนสถานะเป็น "Approved"
|
||||||
|
มีฟังก์ชันสำหรับส่งไฟล์ PDF ของ PO ให้ผู้ขายผ่านทางอีเมลโดยตรงจากระบบ
|
||||||
|
สามารถปิดใบสั่งซื้อโดยอัตโนมัติ เมื่อมีการรับพัสดุครบตามจำนวนหรือรายการที่สั่งซื้อไป
|
||||||
|
ระบบสามารถพิมพ์ใบสั่งซื้อหลังประมวลผล
|
||||||
|
ใบสั่งซื้อสามารถลงนามด้วยลายเซ็นอิเล็กทรอนิกส์ได้
|
||||||
|
2.3.8 การจัดเก็บและประวัติ
|
||||||
|
สามารถจัดเก็บข้อมูลใบสั่งซื้อ/สั่งจ้างได้ตามมาตรฐานของระบบ ERP ได้ เช่น ราคาต่อหน่วย และสถานที่จัดส่ง
|
||||||
|
สามารถเก็บประวัติการแก้ไขใบสั่งซื้อ/สั่งจ้าง และสามารถพิมพ์รายงานรายละเอียดการแก้ไขใบสั่งซื้อ/สั่งจ้างได้ตามต้องการ
|
||||||
|
ระบบสามารถรองรับการตรวจสอบการเปลี่ยนแปลงแก้ไขรายละเอียดของใบสั่งซื้อ (Change Order)
|
||||||
|
2.3.9 การค้นหาและตรวจสอบ
|
||||||
|
สามารถค้นหาข้อมูลใบสั่งซื้อย้อนหลังโดยค้นหาได้จาก:
|
||||||
|
ผู้จำหน่าย
|
||||||
|
เลขที่ใบสั่งซื้อ
|
||||||
|
ประเภทใบสั่งซื้อ
|
||||||
|
สถานะเอกสาร
|
||||||
|
วันที่สั่งซื้อ
|
||||||
|
ระบบสามารถรองรับการตรวจสอบสถานะของใบสั่งซื้อ
|
||||||
|
ระบบติดตามการสั่งซื้อ เช่น การแจ้งเตือนเมื่อสินค้าใกล้ครบกำหนดส่งมอบ
|
||||||
|
2.3.10 คุณสมบัติเพิ่มเติม
|
||||||
|
สามารถบันทึกรายการบัญชีได้อัตโนมัติหลังจากทำการบันทึกรายการ
|
||||||
|
สามารถรองรับการบันทึกรายการภาษี หัก ณ ที่จ่ายได้หลายรายการและหลายอัตราต่อรายการชำระเดียวกันได้
|
||||||
|
สามารถระบุเงื่อนไขสำคัญอื่นๆ เช่น รูปแบบชำระเงิน (โอนเงินล่วงหน้า) และรายละเอียดภาษีหัก ณ ที่จ่าย
|
||||||
|
ระบบสามารถแนบไฟล์เอกสารต่างๆ ที่เกี่ยวข้อง เมื่อทำการสั่งซื้อ
|
||||||
|
ระบบสามารถกำหนดสิทธิ์ในการแก้ไขราคา การยกเลิก และการเปลี่ยนแปลงของใบสั่งซื้อ
|
||||||
|
ระบบสามารถแสดงรายละเอียดราคาและผู้ขายของสินค้าที่สั่งซื้อโดยอัตโนมัติตามเงื่อนไขที่กำหนดในสินค้า
|
||||||
|
มีระบบการรับวางบิล
|
||||||
|
|
||||||
|
2.4 การรับพัสดุจากผู้ขาย (Goods Receipt Note - GRN)
|
||||||
|
ระบบรองรับการบันทึกการรับมอบสินค้าทางกายภาพอย่างเป็นระบบ ตรวจสอบความถูกต้องเทียบกับใบสั่งซื้อ และเป็นจุดเริ่มต้นของการบันทึกสต็อกและกระบวนการทางบัญชี โดยมีคุณสมบัติอย่างน้อยดังต่อไปนี้:
|
||||||
|
2.4.1 การเริ่มต้นกระบวนการรับของ
|
||||||
|
มีช่องสำหรับค้นหา "ใบสั่งซื้อ (PO)" ที่มีสถานะ "Approved" หรือ "รับของบางส่วนแล้ว" เพื่อเริ่มกระบวนการตรวจรับ
|
||||||
|
สามารถค้นหาข้อมูลใบตรวจรับครุภัณฑ์ย้อนหลัง จาก เลขที่ใบตรวจรับ และวันที่เอกสาร
|
||||||
|
ระบบสามารถรองรับการรับสินค้าโดยไม่อ้างอิงใบสั่งซื้อ
|
||||||
|
ระบบสามารถรองรับการรับสินค้าโดยการอ้างอิงใบสั่งซื้อ ทั้งแบบรับสินค้าเต็มจำนวนและรับสินค้าบางส่วน
|
||||||
|
สามารถรองรับการรับสินค้า/บริการบางส่วนได้
|
||||||
|
2.4.2 การดึงข้อมูลจากใบสั่งซื้อ
|
||||||
|
เมื่อเลือก PO ข้อมูลผู้ขายและรายการสินค้าจะถูกดึงมาที่ฟอร์มโดยอัตโนมัติ
|
||||||
|
ระบบสามารถ Load รายการสินค้าตามใบสั่งซื้อได้
|
||||||
|
2.4.3 ข้อมูลส่วนหัว (Header)
|
||||||
|
ผู้ใช้กรอก:
|
||||||
|
เลขที่ใบแจ้งหนี้ของผู้ขาย
|
||||||
|
วันที่รับของ
|
||||||
|
คลังที่รับ
|
||||||
|
เลขที่ใบส่งของผู้ขาย
|
||||||
|
วัน-เวลาที่รับสินค้าจากบริษัท
|
||||||
|
สามารถระบุได้ว่าต้องการให้ระบบคำนวณเงินที่รวม Vat แล้วและเงินที่หักส่วนลดแล้วในการรับสินค้าแต่ละรายการหรือไม่
|
||||||
|
2.4.4 รายการสินค้า (Item Grid)
|
||||||
|
ผู้ใช้กรอกจำนวนที่รับจริง (Received Quantity)
|
||||||
|
สามารถระบุจำนวนสินค้าที่รับหรือที่แถม เป็นหน่วยบรรจุหรือหน่วยนับได้
|
||||||
|
สามารถระบุจำนวนเงินรวมและมูลค่ารวมของแถมที่ลงบันทึกรับสินค้าของสินค้าที่ระบุได้
|
||||||
|
2.4.5 ฟิลด์บังคับตามเงื่อนไข (Conditional Fields)
|
||||||
|
หากพัสดุถูกตั้งค่าเป็น Is Lot Controlled: ระบบจะบังคับให้กรอก:
|
||||||
|
Lot Number
|
||||||
|
วันหมดอายุ
|
||||||
|
หากพัสดุถูกตั้งค่าเป็น Is Serialized: ระบบจะบังคับให้กรอก:
|
||||||
|
Serial Number ให้ครบตามจำนวนที่รับ
|
||||||
|
สามารถระบุได้ว่าต้องการให้ระบบสร้าง Lot No. ให้อัตโนมัติหรือไม่
|
||||||
|
ระบบสามารถบันทึกเลขที่ผลิต (Lot Number) และวันหมดอายุ (Expire Date) เมื่อรับสินค้า
|
||||||
|
2.4.6 การแนะนำตำแหน่งจัดเก็บ
|
||||||
|
หลังจากกรอกข้อมูลครบถ้วน ระบบสามารถแนะนำ "ตำแหน่งจัดเก็บ (Bin Location)" ที่เหมาะสมในคลังให้ได้
|
||||||
|
2.4.7 การตรวจสอบและคุณภาพ
|
||||||
|
ระบบรองรับกระบวนการตรวจสอบสินค้า (Inspect) และการปฏิเสธการรับสินค้า (Reject)
|
||||||
|
สามารถเก็บข้อมูลเหล่านี้เพื่อใช้ในการประเมินผู้ขาย
|
||||||
|
สามารถแสดงข้อมูลหน่วยนับ หน่วยบรรจุ อัตราส่วนของหน่วยนับต่อหน่วยบรรจุของสินค้าที่ระบุได้
|
||||||
|
2.4.8 การบันทึกและผลลัพธ์ (Save and Post) เมื่อบันทึกแล้ว จะส่งผลให้เกิด 3 เหตุการณ์พร้อมกัน:
|
||||||
|
เพิ่มสต็อกในคลัง (Increase Stock): ปรับปรุงยอดสินค้าคงคลังในระบบบริหารคลัง
|
||||||
|
อัปเดตสถานะใบสั่งซื้อ (Update PO Status): เปลี่ยนสถานะ PO เป็น "รับของบางส่วนแล้ว" หรือ "รับของครบแล้ว"
|
||||||
|
ส่งข้อมูลให้ฝ่ายบัญชี (Trigger AP Process): สร้างรายการ "รอจับคู่ใบแจ้งหนี้" ในโมดูลบัญชีเจ้าหนี้โดยอัตโนมัติเพื่อเตรียมพร้อมสำหรับกระบวนการ 3-Way Matching
|
||||||
|
ระบบสามารถเชื่อมโยงข้อมูลการรับสินค้ากับระบบเจ้าหนี้และระบบสินค้าคงคลัง
|
||||||
|
2.4.9 การจัดการสิทธิ์และการตรวจสอบ
|
||||||
|
สามารถกำหนดสิทธิ์ในการรับสินค้าและยกเลิกการรับสินค้า
|
||||||
|
ระบบสามารถรองรับการตรวจสอบสถานะของการรับสินค้า
|
||||||
|
สามารถตรวจสอบได้ว่าเป็นรายการรับสินค้าที่แผนกบัญชีลงหลักฐานทางบัญชีแล้วหรือไม่
|
||||||
|
สามารถตรวจสอบราคาทุนเฉลี่ยที่เปลี่ยนแปลงตามใบรับสินค้า และแต่ละรายการสินค้าในใบรับสินค้าได้
|
||||||
|
2.4.10 การลงบันทึกรับสินค้า
|
||||||
|
สามารถลงบันทึกรับสินค้าเข้าคลังได้
|
||||||
|
สามารถลงบันทึกรับสินค้าแบบตัดจ่ายให้หน่วยงานในโรงพยาบาลได้
|
||||||
|
สามารถกำหนดสิทธิ์ User ที่จะลงบันทึกรับสินค้าได้
|
||||||
|
2.4.11 การพิมพ์เอกสารและรายงาน สามารถพิมพ์เอกสารและรายงานได้ เช่น:
|
||||||
|
ใบรับสินค้า
|
||||||
|
รายงานสรุปการรับสินค้า
|
||||||
|
รายงานเจ้าหนี้การค้า
|
||||||
|
การพิมพ์ Barcode/QR code บนใบรับสินค้า
|
||||||
|
2.4.12 การจัดการราคาและต้นทุน
|
||||||
|
สามารถระบุจำนวนเงินส่วนลดของการรับสินค้าได้
|
||||||
|
สามารถระบุได้ว่าต้องคิด Vat ในการรับสินค้าหรือไม่ และสามารถระบุจำนวนเปอร์เซ็นต์ในการคิด Vat ได้
|
||||||
|
สามารถระบุได้ว่าต้องคิดส่วนลดในการรับสินค้าหรือไม่ และสามารถระบุจำนวนเปอร์เซ็นต์ในการคิดส่วนลดได้
|
||||||
|
สามารถคำนวณจำนวนเงินรวมทั้งหมดที่ลงบันทึกรับสินค้าได้
|
||||||
|
สามารถคำนวณต้นทุนสินค้ารับคืนได้อย่างถูกต้องตามหลักการบัญชีที่รับรองทั่วไป
|
||||||
|
|
||||||
|
2.5 การคืนสินค้าให้ผู้ขาย (Return to Supplier)
|
||||||
|
2.5.1 การบันทึกคืนสินค้า
|
||||||
|
สามารถระบุรหัสคลังสินค้า เลขที่ใบรับสินค้า หมายเหตุที่เกี่ยวข้อง และรหัสสินค้าตามรายการกับการบันทึกคืนสินค้าได้
|
||||||
|
สามารถแสดงข้อมูลราคาทุน หน่วยนับ หน่วยบรรจุ และอัตราส่วนของหน่วยนับต่อหน่วยบรรจุได้
|
||||||
|
2.5.2 การแสดงข้อมูล
|
||||||
|
สามารถแสดงจำนวนสินค้าเดิมเป็นหน่วยนับและหน่วยบรรจุได้
|
||||||
|
สามารถแสดงวันที่เบิกครั้งสุดท้ายของสินค้าที่ระบุได้
|
||||||
|
สามารถแสดงจำนวนคงเหลือใน Stock และจำนวนที่ใช้สินค้าไปแล้ว เป็นหน่วยนับและหน่วยบรรจุได้
|
||||||
|
สามารถแสดงจำนวนสินค้าและจำนวนเงินที่ลงบันทึกคืนสินค้าของแต่ละรายการได้ และจำนวนเงินรวมทั้งหมดที่คืนสินค้าได้
|
||||||
|
2.5.3 การดำเนินการคืนสินค้า
|
||||||
|
สามารถระบุจำนวนที่จะคืนเป็นหน่วยบรรจุหรือหน่วยนับได้
|
||||||
|
สามารถคำนวณจำนวนเงินที่จะคืนได้
|
||||||
|
สามารถ Load รายการสินค้าตามเลขที่ใบรับสินค้าที่ระบุไว้ได้
|
||||||
|
สามารถกำหนดสิทธิ์ User ที่สามารถคืนสินค้าได้
|
||||||
|
สามารถพิมพ์ใบคืนสินค้าได้
|
||||||
|
สามารถทำการลดหนี้การสั่งซื้อ และออกเอกสารใบลดหนี้การสั่งซื้อได้
|
||||||
|
|
||||||
|
2.6 เอกสารและรายงานการจัดซื้อ
|
||||||
|
2.6.1 การสร้างและจัดการฟอร์มเอกสาร
|
||||||
|
มีเครื่องมือในการสร้างรูปแบบฟอร์มเอกสารใบเสนอราคา สั่งซื้อ/จัดจ้าง ใช้งานในปัจจุบันและปรับเปลี่ยนรูปแบบได้ในอนาคต
|
||||||
|
สามารถพิมพ์เอกสารดังกล่าวได้ และแสดงผลเป็นเอกสารหรือไฟล์ข้อมูลแบบ PDF, .xls
|
||||||
|
สามารถเรียกดู/พิมพ์รายการที่ทำการขอซื้อ สั่งซื้อ และรับของเข้าคลังผ่านทางระบบได้ทั้ง 2 รูปแบบคือ PDF, Excel
|
||||||
|
2.6.2 รายงานมาตรฐาน
|
||||||
|
มีรายงานมาตรฐานและมีเครื่องมือสร้างรายงานเพิ่มเติมให้สามารถตอบสนองต่อความต้องการของผู้ใช้งานได้
|
||||||
|
รายงานดังกล่าวสามารถแสดงออกมาในรูปแบบรายงานพร้อมพิมพ์และสามารถบันทึกออกมาในรูปแบบของไฟล์เอกสาร Excel
|
||||||
|
ระบบสามารถออกรายงานการตรวจสอบสินค้า
|
||||||
|
ระบบสามารถออกรายงานการขอซื้อ
|
||||||
|
ระบบสามารถออกรายงานการสั่งซื้อ
|
||||||
|
ระบบสามารถออกรายงานการรับสินค้าประจำวัน
|
||||||
|
ระบบสามารถออกรายงานสินค้าค้างส่ง
|
||||||
|
2.6.3 รายงานภาพรวมการจัดซื้อ
|
||||||
|
สามารถเรียกดูรายงานข้อมูลการจัดซื้อจัดจ้าง ในลักษณะของภาพรวมทั้งระบบงาน ตั้งแต่:
|
||||||
|
กระบวนการขอซื้อขอจ้าง (PR)
|
||||||
|
การอนุมัติขอซื้อขอจ้าง (แสดงข้อมูลงบประมาณ)
|
||||||
|
ข้อมูลการเสนอราคา
|
||||||
|
ข้อมูลการคัดเลือกผู้ค้า
|
||||||
|
ข้อมูลสัญญาซื้อ/จ้าง หรือใบสั่งซื้อ/จ้าง (PO)
|
||||||
|
ข้อมูลการส่งมอบงาน
|
||||||
|
ข้อมูลผลการตรวจรับ
|
||||||
|
ข้อมูลที่บันทึกในระบบบัญชีเจ้าหนี้และรายงานงบประมาณ
|
||||||
|
2.6.4 การแสดงข้อมูลแบบ Real Time
|
||||||
|
สามารถแสดงข้อมูลสรุปการจัดซื้อจัดจ้างแบบ Real Time หรือตามเงื่อนไขเวลาที่เลือก
|
||||||
|
สามารถแสดงข้อมูลการจัดซื้อจัดจ้างตามประเภทงานซื้อ/งานจ้าง ตามวิธีการจัดซื้อจัดจ้าง
|
||||||
|
ข้อมูลรายงานแบบ Real Time นำไปใช้ได้ทันที
|
||||||
|
|
||||||
|
2.7 การเชื่อมโยงระบบและการทำงานอัตโนมัติ
|
||||||
|
2.7.1 การเชื่อมโยงข้อมูล
|
||||||
|
สามารถเชื่อมโยงข้อมูลทางบัญชีได้กับระบบอื่นๆ เช่น:
|
||||||
|
ระบบเจ้าหนี้
|
||||||
|
ระบบบัญชีแยกประเภททั่วไป/งบประมาณ
|
||||||
|
ระบบบริหารสินค้าคงคลัง
|
||||||
|
ระบบสินทรัพย์ถาวร
|
||||||
|
ระบบสามารถทำการเชื่อมโยงข้อมูลการบันทึกบัญชีกับระบบบัญชีแยกประเภท (General Ledger)
|
||||||
|
ระบบสามารถทำการเชื่อมโยงข้อมูลการสั่งซื้อทรัพย์สินกับระบบทรัพย์สิน (Asset Management)
|
||||||
|
ระบบสามารถทำการเชื่อมโยงข้อมูลการรับสินค้ากับระบบเจ้าหนี้ (Accounts Payable)
|
||||||
|
ระบบสามารถทำการเชื่อมโยงข้อมูลการรับสินค้ากับระบบสินค้าคงคลัง (Inventory)
|
||||||
|
ระบบสามารถทำการเชื่อมโยงข้อมูลการตรวจสอบงบประมาณกับงบประมาณที่ได้ทำการกำหนดไว้ (Commitment Control)
|
||||||
|
2.7.2 การเชื่อมโยงข้อมูลระหว่างหน่วยงาน
|
||||||
|
การเชื่อมโยงของระบบข้อมูลระหว่างหน่วยงานที่เกี่ยวข้อง เช่น:
|
||||||
|
งบประมาณ
|
||||||
|
จัดซื้อพัสดุ
|
||||||
|
บัญชี
|
||||||
|
รองรับระบบการจัดเก็บข้อมูลของระบบงานที่เกี่ยวข้องมารวมกัน เพื่อง่ายต่อการตรวจสอบ จัดเก็บและค้นหาข้อมูล
|
||||||
|
2.7.3 ระบบอนุมัติและ Workflow
|
||||||
|
รองรับการกำหนด แก้ไข และเพิ่มเติมค่าการตั้งค่าของขั้นตอนในการอนุมัติให้จัดซื้อจัดจ้างตามได้ตามกำหนด
|
||||||
|
สามารถรองรับการจัดทำเอกสารการจัดซื้อจัดจ้างให้สอดคล้องกับข้อบังคับ/ระเบียบ/ประกาศที่เกี่ยวข้อง
|
||||||
|
พร้อมทั้งจัดพิมพ์เอกสารที่เกี่ยวข้องในระบบงานจัดซื้อจัดจ้างตามที่กำหนดได้
|
||||||
|
|
||||||
|
2.8 คุณสมบัติเพิ่มเติมของระบบจัดซื้อ
|
||||||
|
2.8.1 การวางแผนและเตือนการสั่งซื้อ
|
||||||
|
สามารถวางแผน กำหนดจุดสั่งซื้อ และมีระบบเตือนเพื่อเชื่อมโยงข้อมูลไปยังระบบการสั่งซื้อเพิ่มได้
|
||||||
|
สามารถสร้างใบสั่งซื้อให้อัตโนมัติจากใบขอซื้อ
|
||||||
|
รองรับการเก็บต้นทุนรูปแบบต่างๆ ตั้งแต่การรับวัตถุดิบจนถึงการใช้วัตถุดิบในการบริหารสินค้าที่เป็น Lot หรือ Serial
|
||||||
|
2.8.2 การใช้งานผ่านอุปกรณ์ต่างๆ
|
||||||
|
สามารถใช้งานโปรแกรมได้บน PC, Tablet และมือถือได้
|
||||||
|
2.8.3 การจัดการกรรมการ
|
||||||
|
สามารถกำหนดรายชื่อกรรมการตรวจรับพัสดุ หรือ กรรมการจัดซื้อโดยวิธีต่างๆ ได้
|
||||||
|
สามารถระบุรายชื่อกรรมการเปิดซองและกรรมการตรวจรับสินค้าได้
|
||||||
|
2.8.4 การจัดการงบประมาณ
|
||||||
|
สามารถระบุงบประมาณที่ใช้ในการจัดซื้อได้
|
||||||
|
สามารถระบุหมายเหตุที่เกี่ยวข้องกับงบประมาณได้
|
||||||
|
สามารถระบุจำนวนเงินก่อนรวม VAT, จำนวน VAT, จำนวนเงินรวม, เงินประกัน และจำนวนเงินส่วนลดในภาพรวมได้
|
||||||
|
2.8.5 เงื่อนไขการจัดซื้อ
|
||||||
|
สามารถระบุเงื่อนไขพิเศษอื่นๆ หรือเงื่อนไขในการส่งสินค้าเพิ่มเติมในการจัดซื้อได้
|
||||||
|
สามารถระบุวันที่สรุป วันที่ยื่นเอกสาร ชื่อเจ้าหน้าที่ผู้รับยื่นซอง วันที่กำหนดส่งเอกสาร และวันที่ลงนามได้
|
||||||
|
สามารถระบุวันที่กำหนดส่งของได้ และสามารถเลือกให้คำนวณได้อัตโนมัติตามวันหยุดราชการตามที่ราชการประกาศในแต่ละปีได้
|
||||||
|
สามารถคำนวณวันที่กำหนดชำระเงินจาก Credit Term ที่กำหนดไว้กับรหัสบริษัทได้
|
||||||
1392
references/tor.md
Normal file
1392
references/tor.md
Normal file
File diff suppressed because it is too large
Load Diff
1265
references/warehouse-gap-analysis.md
Normal file
1265
references/warehouse-gap-analysis.md
Normal file
File diff suppressed because it is too large
Load Diff
1765
references/warehouse-implementation-todo.md
Normal file
1765
references/warehouse-implementation-todo.md
Normal file
File diff suppressed because it is too large
Load Diff
435
references/warehouse.txt
Normal file
435
references/warehouse.txt
Normal file
@@ -0,0 +1,435 @@
|
|||||||
|
# โมดูล 3: การบริหารคลังพัสดุ (Warehouse Management System)
|
||||||
|
|
||||||
|
## 3.1 การจัดการคลังพัสดุทั่วไป
|
||||||
|
|
||||||
|
ระบบรองรับการบริหารจัดการคลังพัสดุอย่างครบวงจร ตั้งแต่การรับเข้า การจ่ายออก การโอนย้าย และการปรับปรุงสต็อก โดยมีคุณสมบัติอย่างน้อยดังต่อไปนี้:
|
||||||
|
|
||||||
|
### 3.1.1 โครงสร้างคลังและสถานที่จัดเก็บ
|
||||||
|
- สามารถสร้างคลังสินค้าย่อยเพื่อรองรับการควบคุมการเบิกใช้งาน รวมทั้งสามารถโอนย้ายสินค้า/พัสดุระหว่างคลังใหญ่และคลังย่อยได้
|
||||||
|
- ระบบสามารถกำหนดรายละเอียดของคลังสินค้าหลักและคลังสินค้าย่อย (`Main Store`/`Sub Store`) รวมถึงรายการสินค้าในแต่ละคลังสินค้าได้
|
||||||
|
- ระบบสามารถแยกสถานที่ (`Location`) ในการจัดเก็บสินค้าคงคลังกับสินค้าฝากขาย (`Consignment`) ได้ชัดเจน เพื่อการควบคุมภายในยอดคงเหลือ
|
||||||
|
- ระบบสามารถระบุสถานที่จัดเก็บสินค้าแต่ละชนิด รวมถึงการจัดเก็บสินค้าของคลังสินค้าแต่ละแห่งที่มีการควบคุมตามชั้นแถว เช่น วันรับของ วันหมดอายุ (`Lot Control`)
|
||||||
|
|
||||||
|
### 3.1.2 การรับพัสดุเข้าคลัง
|
||||||
|
- สามารถเชื่อมโยงกับระบบงานพัสดุในด้านการรับสินค้าเข้าคลังได้
|
||||||
|
- ระบบสามารถรับยาเข้าคลังย่อยจากคลังยาใหญ่, รับคืนจากหอผู้ป่วย
|
||||||
|
- รองรับการรับพัสดุจากหลายช่องทาง:
|
||||||
|
- การรับจากผู้ขาย
|
||||||
|
- การรับโอนจากคลังอื่น
|
||||||
|
- การรับคืนจากหน่วยงาน
|
||||||
|
- การรับของแถม วัสดุ และครุภัณฑ์จากการสั่งซื้อ
|
||||||
|
|
||||||
|
### 3.1.3 การตรวจสอบสินค้าคงคลัง
|
||||||
|
- สามารถตรวจสอบสินค้าคงคลังผ่านทางระบบได้หลายรูปแบบ คือ:
|
||||||
|
- `Stock Card`
|
||||||
|
- `Stock Movements`
|
||||||
|
- `Stock Summary`
|
||||||
|
- สามารถค้นหาพัสดุเพื่อดูยอดคงเหลือของพัสดุที่อยู่ในคลังได้ โดยสามารถแสดงแบบรายการทั้งหมด หรือดูยอดรวมของพัสดุแต่ละรายการ
|
||||||
|
- ระบบสามารถแสดงรายละเอียดการเคลื่อนไหวของสินค้าในคลังได้
|
||||||
|
- สามารถดู `stock card movement` ได้แบบ real time
|
||||||
|
- สามารถตรวจสอบข้อมูลยอดคงเหลือตามแต่ละคลังสินค้า หรือทั้งหมดของโรงพยาบาลได้
|
||||||
|
|
||||||
|
### 3.1.4 การสอบถามยอดคงเหลือ
|
||||||
|
- สามารถดูข้อมูลยอดคงเหลือของรายการพัสดุของระบบได้ โดยสามารถเรียกดูได้ตาม:
|
||||||
|
- ยอดคงเหลือที่ต่ำกว่าจุดสั่งซื้อ
|
||||||
|
- ต่ำกว่าจุดต่ำสุด
|
||||||
|
- สูงกว่าจุดสูงสุด
|
||||||
|
- ระบบสามารถตรวจสอบยาคงเหลือได้ตลอดเวลา ทั้งที่เป็นยอดปัจจุบัน และยอดคงเหลือย้อนหลังตามช่วงวันที่ระบุ
|
||||||
|
- สามารถแสดงจำนวนคงเหลือและระบุจำนวนสินค้าที่จะจัดซื้อเป็นหน่วยนับและหน่วยบรรจุได้
|
||||||
|
|
||||||
|
### 3.1.5 การแจ้งเตือน
|
||||||
|
- สามารถแจ้งเตือนเมื่อสินค้า/พัสดุไม่พอต่อการขายหรือทำการโอนย้าย
|
||||||
|
- ระบบแจ้งเตือนเมื่อจำนวนวัสดุคงคลังใกล้หมด/ของหมด
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.2 การขอเบิกพัสดุ (Internal Requisition)
|
||||||
|
|
||||||
|
### 3.2.1 การสร้างใบขอเบิก
|
||||||
|
- สามารถให้คลังย่อยตามแผนกทำใบขอเบิก/ขอโอนผ่านระบบมาที่คลังพัสดุเพื่อขอเบิกพัสดุได้
|
||||||
|
- สามารถให้คลังย่อยทำใบบันทึกขอเบิกผ่านระบบมาที่คลังครุภัณฑ์ได้
|
||||||
|
- สามารถระบุรหัสหน่วยที่ขอเบิกและเลขที่หนังสือ กับหน่วยที่ให้เบิกสินค้าได้ และหมายเหตุอื่นๆ ที่เกี่ยวข้องกับการขอเบิกสินค้าได้
|
||||||
|
- สามารถระบุได้ว่าจะส่งเรื่องขอเบิกสินค้าไปยังหน่วยงานที่ให้เบิกสินค้าหรือไม่
|
||||||
|
- สามารถระบุได้ว่าเป็นการขอเบิกสินค้าแบบเร่งด่วนหรือไม่
|
||||||
|
|
||||||
|
### 3.2.2 การเลือกรายการเบิก
|
||||||
|
- สามารถระบุรหัสสินค้าที่จะขอเบิกสินค้าได้
|
||||||
|
- สามารถระบุจำนวนที่ขอเบิกสินค้าเป็นหน่วยบรรจุ หรือ หน่วยนับได้
|
||||||
|
- สามารถ `Load` รายการสินค้าที่ต่ำกว่า `Safety Level` หรือที่ต่ำกว่า `Max Level` ที่กำหนดไว้ ในการลงบันทึกขอเบิกได้
|
||||||
|
|
||||||
|
### 3.2.3 การอนุมัติใบขอเบิก
|
||||||
|
- หน่วยให้เบิกสามารถอนุมัติรายการขอเบิกสินค้าที่ส่งมาได้
|
||||||
|
- สามารถกำหนดสิทธิ์ `User` ในการอนุมัติรายการขอเบิกสินค้าได้
|
||||||
|
- สามารถตรวจสอบได้ว่ารายการขอเบิกสินค้าได้รับอนุมัติแล้วหรือไม่
|
||||||
|
- สามารถแสดงข้อมูลรหัสผู้ให้อนุมัติรายการขอเบิกสินค้าได้
|
||||||
|
- มีระบบการอนุมัติใบขอเบิกเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากคลังตรวจสอบเอกสารการขอเบิกแล้ว
|
||||||
|
|
||||||
|
### 3.2.4 การค้นหาและติดตาม
|
||||||
|
- สามารถค้นหาข้อมูลใบขอเบิก/ขอโอนย้อนหลังโดยค้นหาได้จาก:
|
||||||
|
- ประเภทเอกสาร
|
||||||
|
- คลัง (ออก)
|
||||||
|
- คลัง (เข้า)
|
||||||
|
- เลขที่เอกสาร
|
||||||
|
- วันที่เอกสาร
|
||||||
|
- คลังขอเบิก
|
||||||
|
- สามารถค้นหารายการครุภัณฑ์ในระบบได้จาก:
|
||||||
|
- รหัสรายการ
|
||||||
|
- ชื่อรายการ
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.3 การจ่ายพัสดุออกจากคลัง (Dispense/Issue)
|
||||||
|
|
||||||
|
### 3.3.1 การดำเนินการจ่ายพัสดุ
|
||||||
|
- สามารถเห็นจำนวนที่คลังย่อยขอเบิกมา และแก้ไขจำนวนที่จะโอนให้กับคลังย่อยใหม่ได้
|
||||||
|
- สามารถบันทึกรายการในหน้าใบโอนออก โดยไม่ต้องเลือกจากใบขอเบิก/ขอโอน ซึ่งระบบให้ใส่ข้อมูล:
|
||||||
|
- ประเภทเอกสาร
|
||||||
|
- คลัง (ออก)
|
||||||
|
- คลัง (เข้า)
|
||||||
|
- แผนกที่ขอ
|
||||||
|
- วันที่เอกสาร
|
||||||
|
- สามารถบันทึกใบโอนออกโดยเลือกจากใบขอเบิก/ขอโอนที่ได้รับการอนุมัติ ซึ่งข้อมูลที่อยู่ในใบขอเบิก/ขอโอนจะเชื่อมโยงมายังใบโอนออก พร้อมกับแสดงเลขที่ใบขอเบิก/ขอโอนที่ดึงมาเป็นใบโอนออก
|
||||||
|
|
||||||
|
### 3.3.2 ระบบอนุมัติใบโอนออก
|
||||||
|
- มีระบบการอนุมัติใบโอนออกเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากการคลังตรวจสอบเอกสารการโอนแล้ว
|
||||||
|
- เมื่ออนุมัติใบโอนออก ระบบตัดสต็อกคลังพัสดุตามจำนวนของแต่ละรายการที่อยู่ในใบโอนออกทันที
|
||||||
|
- การขอเบิกแล้ว และเมื่ออนุมัติใบขอเบิก ระบบตัดสต็อกคลังพัสดุตามจำนวนของแต่ละรายการที่อยู่ในใบขอเบิกออกทันที
|
||||||
|
|
||||||
|
### 3.3.3 การค้นหาและเอกสาร
|
||||||
|
- สามารถค้นหาข้อมูลใบโอนออกย้อนหลังโดยค้นหาได้จาก:
|
||||||
|
- ประเภทเอกสาร
|
||||||
|
- คลัง (ออก)
|
||||||
|
- คลัง (เข้า)
|
||||||
|
- เลขที่เอกสาร
|
||||||
|
- วันที่เอกสาร
|
||||||
|
- สามารถค้นหาข้อมูลใบอนุมัติการเบิกย้อนหลังโดยค้นหาได้จาก คลังขอเบิก เลขที่เอกสาร และวันที่เอกสาร
|
||||||
|
- สามารถทำสำเนาเอกสารจากใบขอเบิก/ขอโอน ใบโอนออกได้โดยการเลือกต้นฉบับจากใบเดิม แล้วทำสำเนามาเป็นใบใหม่ เลขที่จะเปลี่ยนให้อัตโนมัติ
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.4 การรับพัสดุเข้าคลังย่อย (Sub-Warehouse Receipt)
|
||||||
|
|
||||||
|
### 3.4.1 การดำเนินการรับของ
|
||||||
|
- สามารถค้นหาข้อมูลใบรับของโอนย้อนหลังโดยค้นหาได้จาก:
|
||||||
|
- ประเภทเอกสาร
|
||||||
|
- คลัง (ออก)
|
||||||
|
- คลัง (เข้า)
|
||||||
|
- เลขที่เอกสาร
|
||||||
|
- วันที่เอกสาร
|
||||||
|
- แสดงรายการและจำนวนที่คลังหลักจ่ายมา ผู้ใช้กรอกจำนวนที่รับจริง (`Received Quantity`) เพื่อยืนยัน
|
||||||
|
|
||||||
|
### 3.4.2 ระบบอนุมัติใบรับของโอน
|
||||||
|
- มีระบบการอนุมัติใบรับของโอนเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากการคลังย่อยตรวจสอบเอกสารการโอนแล้ว
|
||||||
|
- เมื่ออนุมัติใบโอนรับของโอน ระบบเพิ่มสต็อกให้กับคลังย่อยตามจำนวนของแต่ละรายการที่อยู่ในใบรับของโอนทันที
|
||||||
|
|
||||||
|
### 3.4.3 ผลลัพธ์การบันทึก
|
||||||
|
- **เพิ่มสต็อกในคลังย่อย (Increase Stock):** ปรับปรุงยอดสินค้าคงคลังในคลังย่อยของผู้ใช้
|
||||||
|
- **อัปเดตสถานะการจัดส่ง:** เปลี่ยนสถานะของรายการจัดส่งเป็น "รับของแล้ว"
|
||||||
|
- **สร้างรายการรอรับ:** สร้างรายการ "รอรับเข้าคลังย่อย" เพื่อให้หน่วยงานปลายทางดำเนินการต่อ
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.5 การโอนย้ายพัสดุระหว่างคลัง (Inter-Warehouse Transfer)
|
||||||
|
|
||||||
|
### 3.5.1 การโอนย้าย
|
||||||
|
- สามารถรองรับกระบวนการโอนวัสดุ การยืม การคืน ระหว่างสถานที่จัดเก็บและระหว่างหน่วยงานได้
|
||||||
|
- สามารถโอนยอดสินค้าระหว่างคลังสินค้าได้
|
||||||
|
- ระบบสามารถทำการโอนย้ายสินค้าจากคลังสินค้าได้
|
||||||
|
|
||||||
|
### 3.5.2 การบันทึกข้อมูล
|
||||||
|
- ระบบให้ใส่ข้อมูล:
|
||||||
|
- ประเภทเอกสาร
|
||||||
|
- คลัง (ออก)
|
||||||
|
- คลัง (เข้า)
|
||||||
|
- แผนกที่ขอ
|
||||||
|
- วันที่เอกสาร
|
||||||
|
- เจ้าหน้าที่จะต้องยืนยันการหยิบโดย:
|
||||||
|
- เดินไปยังตำแหน่งที่ระบบแนะนำ
|
||||||
|
- สแกนบาร์โค้ดของ `Bin Location` และ/หรือ `Lot Number`
|
||||||
|
- กรอกจำนวนที่จ่ายจริง (`Dispensed Quantity`)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.6 การปรับปรุงยอดพัสดุ (Stock Adjustment)
|
||||||
|
|
||||||
|
### 3.6.1 การปรับปรุงยอด
|
||||||
|
- สามารถทำการปรับปรุงยอดคงเหลือของรายการพัสดุ พร้อมทั้งสามารถใส่หมายเหตุในการปรับปรุงยอด เมื่อมีการตรวจนับรายการพัสดุ
|
||||||
|
- สามารถทำการปรับปรุงจำนวนสินค้าจากการตรวจนับ (`Stock Count`) ได้
|
||||||
|
- สามารถลงบันทึกปรับ `Stock` โดยการนำเข้าได้
|
||||||
|
- สามารถลงบันทึกปรับ `Stock` โดยการจ่ายออกได้
|
||||||
|
- สามารถทำการปรับปรุงราคาสินค้า (`Adjust Cost`) กรณีที่ต้นทุนสินค้าไม่ถูกต้อง
|
||||||
|
|
||||||
|
### 3.6.2 ประเภทการปรับยอด
|
||||||
|
- ผู้ใช้ต้องเลือกประเภทการปรับยอดจาก `Dropdown` เช่น:
|
||||||
|
- "ตัดใช้ภายใน (Internal Use)"
|
||||||
|
- "ชำรุด (Damaged)"
|
||||||
|
- "ปรับยอดจากการตรวจนับ (Stock Count Adjustment)"
|
||||||
|
- ฐานข้อมูลเหตุผลการ `Adjust`
|
||||||
|
|
||||||
|
### 3.6.3 การดำเนินการ
|
||||||
|
- ผู้ใช้ค้นหาและเลือกพัสดุที่มีอยู่ในคลังย่อยของตนเอง
|
||||||
|
- ระบบแสดง `Lot Number` ที่มีให้เลือก
|
||||||
|
- ผู้ใช้กรอกจำนวนที่ปรับปรุง (`Quantity Adjusted`) (สามารถเป็นค่าบวกหรือลบได้)
|
||||||
|
- ระบบปรับปรุงสต็อกในคลังย่อยตามจำนวนและประเภทที่ระบุ
|
||||||
|
- สามารถกำหนดสิทธิ์ `User` ในการปรับ `Stock` ได้
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.7 การตรวจนับสต็อก (Cycle Counting)
|
||||||
|
|
||||||
|
### 3.7.1 การบริหารจัดการแผนการตรวจนับ (สำหรับผู้จัดการคลัง)
|
||||||
|
- ผู้จัดการคลังสามารถสร้าง "แผนการตรวจนับ" ได้หลายรูปแบบ เช่น:
|
||||||
|
- ตามความถี่: "พัสดุมูลค่าสูง (กลุ่ม A) - ตรวจนับทุกเดือน", "พัสดุทั่วไป (กลุ่ม C) - ตรวจนับทุก 6 เดือน"
|
||||||
|
- ตามตำแหน่ง: "ตรวจนับสินค้าใน Aisle 1-5 ในไตรมาสที่ 1"
|
||||||
|
- ในแผนจะประกอบด้วย "รายการตรวจสอบ (Checklist)" และ "ความถี่ (Frequency)"
|
||||||
|
|
||||||
|
### 3.7.2 การดำเนินการตรวจนับ (สำหรับเจ้าหน้าที่คลัง)
|
||||||
|
- ระบบจะสร้าง "Task การตรวจนับ" ประจำวัน/สัปดาห์โดยอัตโนมัติตามแผน และมอบหมายให้เจ้าหน้าที่
|
||||||
|
- เจ้าหน้าที่ใช้ `Tablet` หรือ `Mobile App` เพื่อเปิด `Task` ของตนเอง
|
||||||
|
- **กระบวนการตรวจนับ (Blind Count):**
|
||||||
|
- ระบบจะแสดงตำแหน่ง (`Bin Location`) และชื่อพัสดุที่ต้องไปนับ แต่จะไม่แสดงจำนวนคงเหลือในระบบ
|
||||||
|
- เจ้าหน้าที่ไปที่ตำแหน่งนั้นและทำการนับจำนวนจริง แล้วกรอกลงในแอปฯ
|
||||||
|
- สามารถตรวจสอบข้อมูลสินทรัพย์ของแต่ละหน่วยงาน ด้วยการยิง `QR Code` ผ่าน `Application` มือถือและออกรายงานผลการตรวจนับ
|
||||||
|
|
||||||
|
### 3.7.3 การตรวจสอบและอนุมัติผลต่าง (Variance Reconciliation)
|
||||||
|
- ระบบจะสร้าง "รายงานผลต่าง" เปรียบเทียบจำนวนที่นับได้กับจำนวนในระบบ
|
||||||
|
- ผู้จัดการคลังตรวจสอบรายงาน และทำการ "อนุมัติ" การปรับยอด
|
||||||
|
- ระบบจะสร้างเอกสาร `Stock Count Adjustment` โดยอัตโนมัติเพื่อปรับปรุงสต็อกให้ถูกต้อง
|
||||||
|
- มีรายงานสำหรับการตรวจนับวัสดุและผลการตรวจนับวัสดุได้ตามกำหนดเวลาที่ต้องการ
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.8 การจัดการข้อมูลและรายงานคลัง
|
||||||
|
|
||||||
|
### 3.8.1 การกำหนดรูปแบบเอกสาร
|
||||||
|
- สามารถกำหนดรูปแบบเลขที่ใบขอเบิก/ขอโอน ใบโอนออก และใบรับของโอนให้อัตโนมัติ โดยจะแยกตามประเภทเอกสาร
|
||||||
|
- ถ้าประเภทเอกสารใบโอนออกต่างกัน รูปแบบเลขที่เอกสารจะต่างกัน
|
||||||
|
|
||||||
|
### 3.8.2 เอกสารแบบฟอร์ม
|
||||||
|
- ระบบรองรับการพิมพ์เอกสารดังต่อไปนี้:
|
||||||
|
- ใบโอนออก
|
||||||
|
- ใบรับของโอน
|
||||||
|
- ใบขอเบิก/ขอโอน
|
||||||
|
- ใบรายการยอดคงเหลือ
|
||||||
|
- ใบปรับปรุงยอดคงเหลือ
|
||||||
|
- ใบยืมพัสดุ/ใบคืนพัสดุ
|
||||||
|
- ใบเบิกวัสดุ
|
||||||
|
|
||||||
|
### 3.8.3 รายงานต่างๆ
|
||||||
|
- ระบบสามารถออกรายงานได้หลากหลาย ได้แก่:
|
||||||
|
- รายงานการตรวจสอบการรับ-พัสดุ
|
||||||
|
- รายงานการตรวจสอบการรับ-จ่ายพัสดุ
|
||||||
|
- รายงานข้อมูลเกี่ยวกับการจ่ายวัสดุออกจากคลัง จำแนกตามส่วนงานและประเภทวัสดุ
|
||||||
|
- รายงานข้อมูลเกี่ยวกับการขอเบิกวัสดุเกินมาตรฐานที่กำหนด
|
||||||
|
- รายงานสินค้าคงคลังแยกตามประเภทสินค้า ตามหน่วยคลัง
|
||||||
|
- รายงานสินค้าค้างรับ
|
||||||
|
- รายงานการรับแจ้งหนี้จากผู้ขาย
|
||||||
|
- รายงานเกี่ยวกับความเคลื่อนไหวของวัสดุครุภัณฑ์
|
||||||
|
- รายงานสรุปยอดพัสดุคงคลัง
|
||||||
|
|
||||||
|
### 3.8.4 รายงานยอดคงเหลือและความเคลื่อนไหว
|
||||||
|
- รายงานข้อมูลเกี่ยวกับวัสดุคงเหลือเป็นปัจจุบัน
|
||||||
|
- รายงานข้อมูลเกี่ยวกับยอดวัสดุคงเหลือขั้นต่ำ ณ จุดสั่งซื้อ
|
||||||
|
- รายงานข้อมูลเกี่ยวกับยอดการรับเข้า-จ่ายออกและคงเหลือ
|
||||||
|
- รายงานข้อมูลเกี่ยวการเปรียบเทียบการรับเข้า-จ่ายออกระหว่างงวด
|
||||||
|
- รายงานข้อมูลเกี่ยวกับราคาซื้อวัสดุครุภัณฑ์ครั้งล่าสุด
|
||||||
|
- รายงานข้อมูลเกี่ยวกับรายละเอียดของครุภัณฑ์และยอดคงคลังประจำงวดและเวลา
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.9 คลังเวชภัณฑ์และยา (Pharmacy Warehouse)
|
||||||
|
|
||||||
|
ระบบรองรับการบริหารจัดการคลังเวชภัณฑ์และยาโดยเฉพาะ โดยมีคุณสมบัติอย่างน้อยดังต่อไปนี้:
|
||||||
|
|
||||||
|
### 3.9.1 การควบคุมสต็อกเวชภัณฑ์และยา
|
||||||
|
- ระบบการควบคุมยาและเวชภัณฑ์ใช้ในการบันทึกข้อมูลยาและเวชภัณฑ์ โดยสามารถควบคุมการรับ-จ่าย-โอนยาจากทั้งคลังยาใหญ่และคลังยาย่อยหลายๆ แห่ง
|
||||||
|
- บันทึกการรับ-จ่าย-โอนเป็นแบบ `Real-Time System` ทำให้สามารถทราบจำนวนยาที่เหลืออยู่ในคลังยาที่คุม `Stock` ได้ทุกขณะของการทำงาน
|
||||||
|
- สามารถค้นหารายการยา/เวชภัณฑ์เพื่อดูยอดคงเหลือของยา/เวชภัณฑ์ที่อยู่ในคลังได้ โดยสามารถแสดงแบบรายการทั้งหมด หรือดูยอดรวมของยา/เวชภัณฑ์แต่ละรายการ
|
||||||
|
- ระบบสามารถแสดงข้อมูลปริมาณ `Stock` ยาและเวชภัณฑ์ของคลังยาแต่ละห้องจ่ายยา เพื่อช่วยในการบริหารคลังยา
|
||||||
|
- สามารถเชื่อมโยงข้อมูลไปยังระบบจัดซื้อจัดจ้าง และระบบขายยาและเวชภัณฑ์ของ `HIS` ได้
|
||||||
|
|
||||||
|
### 3.9.2 การจัดการวันหมดอายุ
|
||||||
|
- มีระบบการเตือนยาตัวใด `Lot` ใดใกล้หมดอายุ เพื่อสะดวกในการส่งไปแลกเปลี่ยนหรือจำหน่ายยาตัวนั้นออกจากคลังยา
|
||||||
|
- สามารถตรวจสอบรายการยาและเวชภัณฑ์ตามวันหมดอายุได้ โดยระบุระยะเวลาที่ยา/เวชภัณฑ์จะหมดอายุภายในระยะเวลาเป็นเดือนหรือวันและสามารถสั่งพิมพ์ได้
|
||||||
|
- สามารถระบุวันหมดอายุของสินค้าหรือของแถมที่ระบุได้
|
||||||
|
|
||||||
|
### 3.9.3 การจัดการข้อมูลยาและเวชภัณฑ์
|
||||||
|
- สามารถบันทึกข้อมูลรายการพัสดุ โดยสามารถบันทึกข้อมูล:
|
||||||
|
- รหัสรายการ
|
||||||
|
- ชื่อการค้า
|
||||||
|
- รหัสกรมบัญชีกลาง
|
||||||
|
- กลุ่มสิทธิ
|
||||||
|
- ราคา `OPD`
|
||||||
|
- ราคา `IPD`
|
||||||
|
- ราคากลางยา
|
||||||
|
- สามารถทำสำเนาของรายการยา/เวชภัณฑ์จากรายการเดิมในระบบมาเป็นรายการใหม่ โดยเมื่อสำเนาเป็นรายการใหม่แล้วสามารถเปลี่ยนแปลงรหัส ชื่อการค้า ชื่อค้นหา ราคาได้ตามต้องการ
|
||||||
|
|
||||||
|
### 3.9.4 การจัดการขอเบิกและจ่ายยา
|
||||||
|
- สามารถให้คลังยาย่อยทำใบขอเบิก/ขอโอนผ่านระบบมาที่คลังยาเพื่อขอเบิกยาได้
|
||||||
|
- สามารถเห็นจำนวนที่คลังยาย่อยขอเบิกมา และแก้ไขจำนวนที่จะโอนให้กับคลังยาย่อยใหม่ได้
|
||||||
|
- สามารถบันทึกใบโอนออกโดยเลือกจากใบขอเบิก/ขอโอนที่ได้รับการอนุมัติ ซึ่งข้อมูลที่อยู่ในใบขอเบิก/ขอโอนจะเชื่อมโยงมายังใบโอนออก พร้อมกับแสดงเลขที่ใบขอเบิก/ขอโอนที่ดึงมาเป็นใบโอนออก
|
||||||
|
- สามารถบันทึกรายการในหน้าใบโอนออก โดยไม่ต้องเลือกจากใบขอเบิกขอโอน
|
||||||
|
- มีระบบการอนุมัติใบโอนออกเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากการคลังตรวจสอบเอกสารการโอนแล้ว และเมื่ออนุมัติใบโอนออก ระบบตัดสต็อกคลังยาตามจำนวนของแต่ละรายการที่อยู่ในใบโอนออกทันที
|
||||||
|
- มีระบบการอนุมัติใบรับของโอนเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากการคลังยาย่อยตรวจสอบเอกสารการโอนแล้ว
|
||||||
|
|
||||||
|
### 3.9.5 การค้นหาเอกสาร
|
||||||
|
- สามารถค้นหาข้อมูลย้อนหลังได้จาก:
|
||||||
|
- ประเภทเอกสาร
|
||||||
|
- คลัง (ออก)
|
||||||
|
- คลัง (เข้า)
|
||||||
|
- เลขที่เอกสาร
|
||||||
|
- วันที่เอกสาร
|
||||||
|
- รองรับการค้นหาสำหรับเอกสารต่อไปนี้:
|
||||||
|
- ใบขอเบิก/ขอโอน
|
||||||
|
- ใบโอนออก
|
||||||
|
- ใบรับของโอน
|
||||||
|
- รายการใบเสนอซื้อ
|
||||||
|
- ใบสั่งซื้อ
|
||||||
|
- ใบตรวจรับพัสดุ
|
||||||
|
|
||||||
|
### 3.9.6 การตั้งค่าและการจัดการ
|
||||||
|
- มีระบบการตั้งค่าจุดต่ำสุด-สูงสุดของรายการยา/เวชภัณฑ์ที่อยู่ในคลัง โดยสามารถกำหนดได้แยกตามจำนวนคลังที่ใช้งาน
|
||||||
|
- สามารถเก็บฐานข้อมูลได้ดังนี้:
|
||||||
|
- `Master`
|
||||||
|
- หน่วยนับ
|
||||||
|
- `Stock Take group`
|
||||||
|
- `Vender/Supplier`
|
||||||
|
- แผนก
|
||||||
|
- การกำหนดสิทธิ์ผู้ใช้
|
||||||
|
- ค่า `Min` คลังและแต่ละห้องยาที่มี `stock`
|
||||||
|
- ฐานข้อมูลเหตุผลการ `Adjust`
|
||||||
|
- การกำหนดประเภทสินค้า (`Pharmaco Category`, `SubCategory`, `SubminorCategory`)
|
||||||
|
|
||||||
|
### 3.9.7 รายงานคลังเวชภัณฑ์และยา
|
||||||
|
- รายงานการตรวจสอบการรับ-จ่ายยาและเวชภัณฑ์
|
||||||
|
- รายงานรายการยาใกล้หมดอายุ
|
||||||
|
- รายงานการรับสินค้า
|
||||||
|
- รายงานสินค้าค้างรับ
|
||||||
|
- รายงานการรับแจ้งหนี้จากผู้ขาย
|
||||||
|
- รายงานสรุปยอดยา/เวชภัณฑ์คงคลัง
|
||||||
|
- รายงานการรับยา/เวชภัณฑ์เข้าคลัง
|
||||||
|
- รายงานเวชภัณฑ์ค้างส่ง ต้องการทราบว่าอยู่ในขั้นตอนใด
|
||||||
|
- มีใบสั่งซื้อยา-เวชภัณฑ์นอกโรงพยาบาล
|
||||||
|
- มีบันทึกข้อความ (ใบขอดำเนินการจัดซื้อ)
|
||||||
|
- มีระบบออกใบสั่งซื้อ
|
||||||
|
- มีบันทึกข้อความ (ใบขออนุมัติจัดซื้อ)
|
||||||
|
- มีบันทึกข้อความ (ใบขออนุมัติเบิกจ่าย)
|
||||||
|
- มีรายงานใบเสนอซื้อเวชภัณฑ์สำรองคลัง
|
||||||
|
- มีรายงานบันทึกการรับพัสดุและการขึ้นบัญชี
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.10 การจัดการคลังขั้นสูง (Advanced Features)
|
||||||
|
|
||||||
|
### 3.10.1 การจัดการหลายหน่วยนับ
|
||||||
|
- สามารถกำหนดหน่วยนับได้หลายหน่วยต่อหนึ่งรหัสสินค้า ตัวอย่างเช่น ยาสามารถระบุหน่วยนับเป็น กล่อง แผง เม็ด ได้
|
||||||
|
- ระบบรองรับการแปลงหน่วยอัตโนมัติ
|
||||||
|
|
||||||
|
### 3.10.2 การจัดการ Lot และ Serial Number
|
||||||
|
- รองรับการบริหารจัดการสินค้าที่เป็น `Lot` หรือ `Serial`
|
||||||
|
- สามารถ ระบุ `Lot Number` ของสินค้าที่ลงบันทึกรับสินค้าได้
|
||||||
|
- สามารถกำหนดได้ว่าต้องการให้ระบบสร้าง `Lot No.` ให้อัตโนมัติหรือไม่
|
||||||
|
|
||||||
|
### 3.10.3 การเตรียมการและจัดส่ง
|
||||||
|
- ระบบสามารถรับข้อมูล `ASN (Advanced Ship Notice)` จากผู้ขาย
|
||||||
|
- เมื่อรถส่งของมาถึง เจ้าหน้าที่คลังสามารถเปิดข้อมูล `ASN` ขึ้นมาเพื่อใช้ในการตรวจรับสินค้าได้ทันที
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.11 งบประมาณและบัญชี
|
||||||
|
|
||||||
|
### 3.11.1 การเชื่อมโยงงบประมาณ
|
||||||
|
- สามารถเชื่อมโยงข้อมูลกับระบบการบริหารงบประมาณในด้านการตัดจ่าย การรับและการจ่ายเงินงบประมาณได้
|
||||||
|
- ระบบการบันทึกงบประมาณยาและเวชภัณฑ์ของยาแต่ละรหัสยาได้
|
||||||
|
- ระบบสามารถเรียกดูแผนงบประมาณยาและเวชภัณฑ์ในปีงบประมาณที่ดำเนินการซื้อไปแล้ว สามารถแสดงผลเป็นแผนภูมิ/กราฟประเภทต่างๆ เช่น แผนภูมิวงกลม
|
||||||
|
- ระบบการตัดงบประมาณราย `Code` ยาที่เชื่อมกับการตรวจรับของเข้า `stock`
|
||||||
|
|
||||||
|
### 3.11.2 การเชื่อมโยงบัญชี
|
||||||
|
- สามารถเชื่อมโยงกับระบบบัญชี เพื่อสามารถนำไปบันทึกบัญชีได้
|
||||||
|
- ระบบสามารถกำหนดรหัสบัญชีแยกประเภทของสินค้าคงคลังได้มากกว่า 1 รหัสบัญชีต่อ 1 คลังสินค้าได้
|
||||||
|
- ระบบสามารถรองรับการลงบัญชีของสินค้าคงคลังได้มากกว่า 1 บัญชีต่อ 1 คลังสินค้าได้
|
||||||
|
- ระบบสามารถทำการบันทึกบัญชีพัก เพื่อใช้ในการตรวจสอบกระทบยอดระหว่างหน่วยงาน (`Sub Module`)
|
||||||
|
- ระบบสามารถตรวจสอบผลการคำนวณต้นทุนสินค้า และการบันทึกบัญชีได้ และสามารถทำการแก้ไขข้อมูลจากระบบสินค้าคงคลังได้
|
||||||
|
- ระบบสามารถตรวจสอบข้อมูลราคาของการสั่งซื้อในแต่ละครั้งได้
|
||||||
|
|
||||||
|
### 3.11.3 การจัดการต้นทุน
|
||||||
|
- ระบบสามารถกำหนดวิธีการคำนวณต้นทุนสินค้าตามนโยบายที่โรงพยาบาลกำหนดได้
|
||||||
|
- สามารถคำนวณต้นทุนสินค้ารับคืนได้อย่างถูกต้องตามหลักการบัญชีที่รับรองทั่วไป
|
||||||
|
- รองรับการเก็บต้นทุนรูปแบบต่างๆ ตั้งแต่การรับวัตถุดิบจนถึงการใช้วัตถุดิบในการบริหารสินค้า
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.12 การบริหารจัดการข้อมูลและการตั้งค่า
|
||||||
|
|
||||||
|
### 3.12.1 การตั้งค่าข้อมูลพื้นฐาน
|
||||||
|
- สามารถบันทึกข้อมูลการเสนอซื้อโดยมีข้อมูลผู้จำหน่าย, ประเภทใบเสนอซื้อ, แผนกที่เสนอซื้อ, ประเภท `VAT`, วิธีการจัดซื้อจัดจ้าง และวันที่เสนอซื้อ
|
||||||
|
- สามารถกำหนดรูปแบบการสั่งซื้อรองรับเรื่องภาษีมูลค่าเพิ่มได้ทั้ง `VATIN`, `VATOUT` หรือ `Exemption` (ไม่มี VAT)
|
||||||
|
- สามารถกำหนดรูปแบบเลขที่ใบเสนอซื้อ, ใบสั่งซื้อ และใบตรวจรับพัสดุให้อัตโนมัติ โดยจะแยกตามประเภทเอกสาร
|
||||||
|
|
||||||
|
### 3.12.2 การกำหนดโครงสร้างงบประมาณ
|
||||||
|
- ใบเสนอซื้อ, ใบสั่งซื้อ และใบตรวจรับพัสดุ สามารถเลือกหมวดค่าใช้จ่าย, แผนงาน, ผลผลิต ตามที่เจ้าหน้าที่เป็นผู้กำหนดได้
|
||||||
|
- สามารถกำหนดราคากลางสำหรับอ้างอิงในการสั่งซื้อได้
|
||||||
|
|
||||||
|
### 3.12.3 การจัดการกรรมการ
|
||||||
|
- ใบเสนอซื้อ, ใบสั่งซื้อ และใบตรวจรับพัสดุ สามารถกำหนดรายชื่อกรรมการตรวจรับพัสดุ หรือกรรมการจัดซื้อโดยวิธีต่างๆ ได้
|
||||||
|
|
||||||
|
### 3.12.4 ระบบอนุมัติเอกสาร
|
||||||
|
- มีระบบการอนุมัติใบเสนอซื้อเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากได้รับการอนุมัติให้ทำเรื่องเสนอซื้อ
|
||||||
|
- มีระบบการอนุมัติใบสั่งซื้อเพื่อป้องกันการแก้ไขเปลี่ยนแปลงเอกสารหลังจากได้รับการอนุมัติให้ทำเรื่องสั่งซื้อ
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3.13 รายงานคลังพัสดุขั้นสูง
|
||||||
|
|
||||||
|
ระบบรองรับการออกรายงานหลากหลายรูปแบบ ได้แก่:
|
||||||
|
|
||||||
|
### 3.13.1 รายงาน Stock Card และ Movement
|
||||||
|
- รายงาน `Stock Card`
|
||||||
|
- รายงาน `Stock Card` แบบสรุปและแจกแจงรายละเอียดได้
|
||||||
|
- รายงาน `Stock Transaction Detail`
|
||||||
|
- รายงานความเคลื่อนไหวสินค้าคงคลัง
|
||||||
|
- สามารถตรวจสอบ `Transaction` ของการเปลี่ยนแปลงปริมาณของรายการสินค้าแต่ละรายการในแต่ละคลังได้
|
||||||
|
|
||||||
|
### 3.13.2 รายงานสินค้าคงเหลือ
|
||||||
|
- รายงานสินค้าคงเหลือ ณ ปัจจุบันได้ (`Stock` คงเหลือประจำวัน)
|
||||||
|
- รายงานสินค้าคงเหลือ ณ วันที่ได้
|
||||||
|
- รายงานสินค้าคงเหลือประจำเดือน (`Stock` คงเหลือประจำเดือน)
|
||||||
|
- รายงานสินค้าใน `Stock` ของแต่ละคลัง/ห้องยา
|
||||||
|
|
||||||
|
### 3.13.3 รายงานการรับและจ่าย
|
||||||
|
- รายงาน `Stock Receive` ตาม `Vendor`
|
||||||
|
- รายงานยารับฝากขาย
|
||||||
|
- รายงานการรับ-รายงานการโอน
|
||||||
|
- รายงานการโอนกลับคลัง `store`
|
||||||
|
- รายงานการโอนต่ำกว่า `Min` ของแต่ละห้องยา
|
||||||
|
- รายงานยอดยาต่ำกว่า `Min` ของแต่ละห้องยา
|
||||||
|
- รายงานการเบิก
|
||||||
|
- รายงานการเบิกของแต่ละหน่วยงาน
|
||||||
|
|
||||||
|
### 3.13.4 รายงานการสั่งซื้อ
|
||||||
|
- รายงานการสั่งซื้อ
|
||||||
|
- รายงานการสั่งซื้อสินค้าต่ำกว่า `Min`
|
||||||
|
- รายงานรายการยาที่ต้องจัดหาคงคลัง
|
||||||
|
|
||||||
|
### 3.13.5 รายงานสินค้าพิเศษ
|
||||||
|
- รายงานยาหมดอายุต่ำกว่า 7 เดือน
|
||||||
|
- รายงานยาใหม่
|
||||||
|
- รายงานใบขออนุมัติเปลี่ยนแปลงข้อมูลยา/เวชภัณฑ์
|
||||||
|
- รายงานยาและเวชภัณฑ์ที่ไม่เคลื่อนไหว
|
||||||
|
|
||||||
|
### 3.13.6 รายงานการจำหน่ายและราคา
|
||||||
|
- รายงานการจำหน่ายตาม `Item`
|
||||||
|
- รายงานการจำหน่ายตาม `Stock Take group`
|
||||||
|
- รายงาน `Price List` แสดงราคายาประเภทต่างๆ (ราคา `OPD`, ราคา `IPD`, ราคาพนักงาน, ราคาทุน)
|
||||||
|
- รายงานราคากลางยา/เวชภัณฑ์
|
||||||
|
|
||||||
|
### 3.13.7 รายงานอื่นๆ
|
||||||
|
- รายงานการ `Adjust`
|
||||||
|
- รายงานยา/เวชภัณฑ์สำรองของหอผู้ป่วยและหน่วยงานต่างๆ
|
||||||
|
- รายงานยา/เวชภัณฑ์ที่เบิกจากคลังยาประจำสัปดาห์ของหอผู้ป่วยและหน่วยงานต่างๆ
|
||||||
|
- รายการแก้ไขสินค้าใน `Master`
|
||||||
|
- ใบรับสินค้า (การพิมพ์ `Barcode`/`QR code`)
|
||||||
|
- รายงาน `Stock Checklist`
|
||||||
|
- รายงานใบตรวจนับยา/เวชภัณฑ์ (`TAG`)
|
||||||
|
- รายงานใบตรวจรับพัสดุ
|
||||||
|
- รายงานการรับพัสดุเข้าคลัง
|
||||||
432
user-guide-pr-approval.md
Normal file
432
user-guide-pr-approval.md
Normal file
@@ -0,0 +1,432 @@
|
|||||||
|
# Purchase Requisition Approval - User Guide
|
||||||
|
|
||||||
|
## Document Information
|
||||||
|
- **Document Type**: User Guide
|
||||||
|
- **Audience**: Procurement Staff, Department Heads, Finance Controllers
|
||||||
|
- **Last Updated**: 2025-10-30
|
||||||
|
- **Version**: 1.0
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This guide explains how to create, submit, and approve Purchase Requisitions (PRs) in the PIAM system. Understanding the approval workflow and document immutability rules is essential for efficient procurement operations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [Purchase Requisition Lifecycle](#purchase-requisition-lifecycle)
|
||||||
|
2. [Creating a Purchase Requisition](#creating-a-purchase-requisition)
|
||||||
|
3. [Submitting for Approval](#submitting-for-approval)
|
||||||
|
4. [Approval Process](#approval-process)
|
||||||
|
5. [Document Immutability Rules](#document-immutability-rules)
|
||||||
|
6. [What You Can and Cannot Do](#what-you-can-and-cannot-do)
|
||||||
|
7. [Common Scenarios](#common-scenarios)
|
||||||
|
8. [Troubleshooting](#troubleshooting)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Purchase Requisition Lifecycle
|
||||||
|
|
||||||
|
A Purchase Requisition moves through several statuses:
|
||||||
|
|
||||||
|
```
|
||||||
|
Draft → Pending Approval → Approved → Converted to RFQ/PO → Closed
|
||||||
|
↑ ↓
|
||||||
|
└────(rejected)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Status Descriptions
|
||||||
|
|
||||||
|
| Status | Description | Can Edit? | Can Approve? |
|
||||||
|
|--------|-------------|-----------|--------------|
|
||||||
|
| **Draft** | Initial state, not yet submitted | ✅ Yes | ❌ No |
|
||||||
|
| **Pending Approval** | Submitted and awaiting approval | ❌ No | ✅ Yes |
|
||||||
|
| **Approved** | Approved and ready for procurement | ❌ No | ❌ No |
|
||||||
|
| **Rejected** | Rejected by approver, returns to Draft | ✅ Yes | ❌ No |
|
||||||
|
| **Converted to RFQ** | Converted to Request for Quotation | ❌ No | ❌ No |
|
||||||
|
| **Converted to PO** | Converted to Purchase Order | ❌ No | ❌ No |
|
||||||
|
| **Closed** | Completed or cancelled | ❌ No | ❌ No |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Creating a Purchase Requisition
|
||||||
|
|
||||||
|
### Step 1: Access the PR Form
|
||||||
|
|
||||||
|
1. Navigate to **Procurement → Purchase Requisitions**
|
||||||
|
2. Click **"Create New Requisition"** button
|
||||||
|
3. The system creates a new PR in **Draft** status
|
||||||
|
|
||||||
|
### Step 2: Fill in Required Information
|
||||||
|
|
||||||
|
#### General Information
|
||||||
|
- **Requisition Number**: Auto-generated by system
|
||||||
|
- **Department**: Select your department from dropdown
|
||||||
|
- **Requested Date**: Date when items are needed
|
||||||
|
- **Purpose**: Describe why these items are needed
|
||||||
|
- **Priority**: Select urgency level
|
||||||
|
|
||||||
|
#### Budget Information
|
||||||
|
- **Budget Code**: Select the budget to charge
|
||||||
|
- **Company Code**: Select company/entity
|
||||||
|
- **Cost Center**: Select appropriate cost center
|
||||||
|
|
||||||
|
#### Line Items
|
||||||
|
For each item you need:
|
||||||
|
1. Click **"Add Item"**
|
||||||
|
2. Search and select the item
|
||||||
|
3. Enter **Quantity** and **Unit**
|
||||||
|
4. Enter **Unit Price** (if known)
|
||||||
|
5. Add **Remarks** if needed
|
||||||
|
|
||||||
|
### Step 3: Save Your Work
|
||||||
|
|
||||||
|
- Click **"Save Draft"** to save without submitting
|
||||||
|
- You can return later to continue editing
|
||||||
|
- Draft PRs remain editable until submitted
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Submitting for Approval
|
||||||
|
|
||||||
|
### When to Submit
|
||||||
|
|
||||||
|
Submit your PR when:
|
||||||
|
- All required information is complete
|
||||||
|
- Line items are accurate
|
||||||
|
- Budget information is correct
|
||||||
|
- You're ready for approval
|
||||||
|
|
||||||
|
### How to Submit
|
||||||
|
|
||||||
|
1. Review all information carefully
|
||||||
|
2. Click **"Submit for Approval"**
|
||||||
|
3. Confirm submission in the dialog
|
||||||
|
4. PR status changes to **"Pending Approval"**
|
||||||
|
|
||||||
|
### What Happens After Submission
|
||||||
|
|
||||||
|
Once submitted:
|
||||||
|
- ❌ **You cannot edit the PR anymore**
|
||||||
|
- ✅ Approvers receive notification
|
||||||
|
- ✅ PR enters the approval workflow
|
||||||
|
- ✅ You can view PR status anytime
|
||||||
|
|
||||||
|
### Important Notes
|
||||||
|
|
||||||
|
- Double-check all details before submitting
|
||||||
|
- Once submitted, you cannot make changes
|
||||||
|
- If rejected, PR returns to Draft for corrections
|
||||||
|
- Keep track of your PR number for reference
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Approval Process
|
||||||
|
|
||||||
|
### Who Can Approve?
|
||||||
|
|
||||||
|
Approvers are typically:
|
||||||
|
- **Department Heads**: For departmental purchases
|
||||||
|
- **Finance Controllers**: For budget approval
|
||||||
|
- **Procurement Managers**: For procurement approval
|
||||||
|
|
||||||
|
*Note: Your organization's approval hierarchy may vary*
|
||||||
|
|
||||||
|
### How to Approve a PR
|
||||||
|
|
||||||
|
1. Navigate to **Procurement → Purchase Requisitions**
|
||||||
|
2. Filter by **"Pending Approval"** status
|
||||||
|
3. Click on the PR to review
|
||||||
|
4. Review all details carefully:
|
||||||
|
- Items requested
|
||||||
|
- Quantities and prices
|
||||||
|
- Budget information
|
||||||
|
- Purpose and justification
|
||||||
|
5. Click **"Approve"** button
|
||||||
|
6. Add approval remarks (optional)
|
||||||
|
7. Confirm approval
|
||||||
|
|
||||||
|
### How to Reject a PR
|
||||||
|
|
||||||
|
If corrections are needed:
|
||||||
|
1. Click **"Reject"** button
|
||||||
|
2. **Add rejection reason** (required)
|
||||||
|
3. Confirm rejection
|
||||||
|
4. PR returns to Draft status
|
||||||
|
5. Requester can make corrections and resubmit
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Document Immutability Rules
|
||||||
|
|
||||||
|
### Why Are Approved PRs Locked?
|
||||||
|
|
||||||
|
Once a PR is approved:
|
||||||
|
- **Financial Control**: Budget is committed
|
||||||
|
- **Audit Compliance**: Approved amounts must be traceable
|
||||||
|
- **Process Integrity**: Prevents unauthorized changes
|
||||||
|
- **Procurement Accuracy**: What was approved is what gets procured
|
||||||
|
|
||||||
|
### Visual Indicators
|
||||||
|
|
||||||
|
When viewing a locked PR, you'll see:
|
||||||
|
- 🔒 **Lock icon** in the header
|
||||||
|
- **"Document Locked"** banner at the top
|
||||||
|
- **"View Only"** badge
|
||||||
|
- All fields are grayed out/disabled
|
||||||
|
- No Save or Submit buttons
|
||||||
|
|
||||||
|
### What Statuses Are Locked?
|
||||||
|
|
||||||
|
| Status | Locked? | Reason |
|
||||||
|
|--------|---------|--------|
|
||||||
|
| Draft | ❌ No | Still being prepared |
|
||||||
|
| Pending Approval | ✅ Yes | In approval workflow |
|
||||||
|
| Approved | ✅ Yes | Budget committed |
|
||||||
|
| Rejected | ❌ No | Returned for correction |
|
||||||
|
| Converted to RFQ/PO | ✅ Yes | Already converted |
|
||||||
|
| Closed | ✅ Yes | Process complete |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What You Can and Cannot Do
|
||||||
|
|
||||||
|
### ✅ What You CAN Do
|
||||||
|
|
||||||
|
**With Draft PRs:**
|
||||||
|
- Edit all fields and line items
|
||||||
|
- Add or remove items
|
||||||
|
- Change quantities and prices
|
||||||
|
- Update budget information
|
||||||
|
- Save changes anytime
|
||||||
|
- Delete the PR if not needed
|
||||||
|
|
||||||
|
**With Approved PRs:**
|
||||||
|
- View all information
|
||||||
|
- Print or export the PR
|
||||||
|
- Track conversion to RFQ/PO
|
||||||
|
- View approval history
|
||||||
|
- View audit logs
|
||||||
|
|
||||||
|
**With Rejected PRs:**
|
||||||
|
- Make requested corrections
|
||||||
|
- Update based on rejection remarks
|
||||||
|
- Resubmit for approval
|
||||||
|
|
||||||
|
### ❌ What You CANNOT Do
|
||||||
|
|
||||||
|
**With Approved PRs:**
|
||||||
|
- Edit any field
|
||||||
|
- Change line items
|
||||||
|
- Modify quantities or prices
|
||||||
|
- Change budget information
|
||||||
|
- Delete the PR
|
||||||
|
|
||||||
|
**With Pending Approval PRs:**
|
||||||
|
- Edit while waiting for approval
|
||||||
|
- Change submitted information
|
||||||
|
- Cancel submission (must be rejected)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Common Scenarios
|
||||||
|
|
||||||
|
### Scenario 1: I Need to Change an Approved PR
|
||||||
|
|
||||||
|
**Problem**: You discovered an error after approval
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Contact your supervisor or procurement manager
|
||||||
|
2. Explain what needs to be changed
|
||||||
|
3. If the PR is not yet converted:
|
||||||
|
- Admin may be able to help
|
||||||
|
- May need to create a new PR
|
||||||
|
4. If already converted to RFQ/PO:
|
||||||
|
- Changes must be made in RFQ/PO document
|
||||||
|
- Original PR remains unchanged for audit
|
||||||
|
|
||||||
|
**Best Practice**: Always double-check before submitting!
|
||||||
|
|
||||||
|
### Scenario 2: My PR Was Rejected
|
||||||
|
|
||||||
|
**Problem**: Your PR status shows "Rejected"
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Open the PR to view rejection remarks
|
||||||
|
2. Review what needs to be corrected
|
||||||
|
3. Make the necessary changes
|
||||||
|
4. Resubmit for approval
|
||||||
|
5. The PR will go through approval again
|
||||||
|
|
||||||
|
### Scenario 3: I Submitted the Wrong PR
|
||||||
|
|
||||||
|
**Problem**: You accidentally submitted a PR that's not ready
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
1. Contact the approver immediately
|
||||||
|
2. Ask them to reject the PR
|
||||||
|
3. Add a note explaining it was submitted early
|
||||||
|
4. Make corrections when it returns to Draft
|
||||||
|
5. Resubmit when ready
|
||||||
|
|
||||||
|
### Scenario 4: I Can't Edit My Draft PR
|
||||||
|
|
||||||
|
**Problem**: The form shows "View Only" even though status is Draft
|
||||||
|
|
||||||
|
**Possible Causes**:
|
||||||
|
1. You're viewing the PR, not editing it
|
||||||
|
- Solution: Click "Edit" button
|
||||||
|
2. You're on the list view or detail view
|
||||||
|
- Solution: Navigate to edit page
|
||||||
|
3. Browser cache issue
|
||||||
|
- Solution: Refresh the page (Ctrl+F5)
|
||||||
|
|
||||||
|
### Scenario 5: System Shows "Document Locked" Error
|
||||||
|
|
||||||
|
**Problem**: You see an error message about document being locked
|
||||||
|
|
||||||
|
**What It Means**:
|
||||||
|
- The PR status doesn't allow editing
|
||||||
|
- This is a security feature to protect approved documents
|
||||||
|
|
||||||
|
**Solution**:
|
||||||
|
- If PR is Pending Approval: Wait for approval/rejection
|
||||||
|
- If PR is Approved: Cannot edit (see Scenario 1)
|
||||||
|
- If you believe this is an error: Contact system administrator
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Troubleshooting
|
||||||
|
|
||||||
|
### Error Messages
|
||||||
|
|
||||||
|
#### "Cannot modify purchase requisition in '[Status]' status"
|
||||||
|
- **Meaning**: PR is locked due to its status
|
||||||
|
- **Solution**: Check PR status; only Draft PRs can be edited
|
||||||
|
|
||||||
|
#### "This document is locked and cannot be edited"
|
||||||
|
- **Meaning**: PR has been approved or is beyond approval
|
||||||
|
- **Solution**: See [Scenario 1](#scenario-1-i-need-to-change-an-approved-pr)
|
||||||
|
|
||||||
|
#### "Purchase requisition not found"
|
||||||
|
- **Meaning**: PR may have been deleted or ID is incorrect
|
||||||
|
- **Solution**: Check PR number and try again
|
||||||
|
|
||||||
|
### Common Issues
|
||||||
|
|
||||||
|
#### Save Button Not Appearing
|
||||||
|
- **Check**: Is PR in Draft status?
|
||||||
|
- **Check**: Are you on the edit page (URL contains `/edit`)?
|
||||||
|
- **Check**: Do you have permission to edit?
|
||||||
|
|
||||||
|
#### Cannot Submit for Approval
|
||||||
|
- **Check**: Are all required fields filled?
|
||||||
|
- **Check**: Are there validation errors?
|
||||||
|
- **Check**: Is at least one line item added?
|
||||||
|
- **Check**: Is budget code valid?
|
||||||
|
|
||||||
|
#### PR Disappeared from List
|
||||||
|
- **Check**: Filter settings (status, date range)
|
||||||
|
- **Check**: Search for PR number directly
|
||||||
|
- **Check**: PR may have been deleted (if it was Draft)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Best Practices
|
||||||
|
|
||||||
|
### Before Creating a PR
|
||||||
|
|
||||||
|
1. ✅ Verify budget availability
|
||||||
|
2. ✅ Gather all item specifications
|
||||||
|
3. ✅ Check with department for requirements
|
||||||
|
4. ✅ Confirm requested delivery date
|
||||||
|
|
||||||
|
### Before Submitting
|
||||||
|
|
||||||
|
1. ✅ Review all line items carefully
|
||||||
|
2. ✅ Verify quantities and units
|
||||||
|
3. ✅ Double-check budget code
|
||||||
|
4. ✅ Ensure purpose is clear
|
||||||
|
5. ✅ Check all required fields are filled
|
||||||
|
6. ✅ Review total amount
|
||||||
|
|
||||||
|
### For Approvers
|
||||||
|
|
||||||
|
1. ✅ Review budget availability
|
||||||
|
2. ✅ Verify items are appropriate
|
||||||
|
3. ✅ Check quantities are reasonable
|
||||||
|
4. ✅ Ensure prices are acceptable
|
||||||
|
5. ✅ Provide clear rejection reasons
|
||||||
|
6. ✅ Approve promptly to avoid delays
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Getting Help
|
||||||
|
|
||||||
|
### Internal Support
|
||||||
|
|
||||||
|
- **Technical Issues**: Contact IT Support
|
||||||
|
- **Approval Questions**: Contact your supervisor
|
||||||
|
- **Budget Questions**: Contact Finance Department
|
||||||
|
- **Procurement Process**: Contact Procurement Department
|
||||||
|
|
||||||
|
### Documentation
|
||||||
|
|
||||||
|
- **System Administrator Guide**: For technical details
|
||||||
|
- **FAQ Document**: For common questions
|
||||||
|
- **Training Materials**: Available from IT Department
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Glossary
|
||||||
|
|
||||||
|
**Draft**: Initial status of a PR, allows editing
|
||||||
|
|
||||||
|
**Immutable**: Cannot be changed or modified
|
||||||
|
|
||||||
|
**Line Item**: A single item/material on the PR
|
||||||
|
|
||||||
|
**Pending Approval**: PR is submitted and awaiting approval
|
||||||
|
|
||||||
|
**Purchase Requisition (PR)**: Internal document requesting to purchase items
|
||||||
|
|
||||||
|
**Rejection Remarks**: Reason provided when PR is rejected
|
||||||
|
|
||||||
|
**Status**: Current state of the PR in its lifecycle
|
||||||
|
|
||||||
|
**Workflow**: Series of steps a PR goes through from creation to approval
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Appendix: Quick Reference
|
||||||
|
|
||||||
|
### Keyboard Shortcuts
|
||||||
|
|
||||||
|
| Shortcut | Action |
|
||||||
|
|----------|--------|
|
||||||
|
| Ctrl+S | Save Draft (on edit page) |
|
||||||
|
| Esc | Close dialog/cancel action |
|
||||||
|
|
||||||
|
### Status Color Codes
|
||||||
|
|
||||||
|
- **Gray**: Draft
|
||||||
|
- **Yellow/Amber**: Pending Approval
|
||||||
|
- **Green**: Approved
|
||||||
|
- **Red**: Rejected
|
||||||
|
- **Blue**: Converted/Closed
|
||||||
|
|
||||||
|
### Important Reminders
|
||||||
|
|
||||||
|
1. 📌 Only Draft PRs can be edited
|
||||||
|
2. 📌 Always review before submitting
|
||||||
|
3. 📌 Approved PRs are permanently locked
|
||||||
|
4. 📌 Save your work frequently
|
||||||
|
5. 📌 Keep PR numbers for reference
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Document End**
|
||||||
|
|
||||||
|
*For technical details and configuration, see System Administrator Guide*
|
||||||
Reference in New Issue
Block a user