Offline Procurement Operations
Overview
Implement offline-first procurement architecture with intelligent caching, prioritized data storage, queuing, background synchronization, conflict resolution for concurrent changes, and data integrity verification. Enables complete procurement functionality without network connectivity.
Announce at start: "I'm using the offline-procurement skill to configure or execute offline procurement operations."
When to Use This Skill
Trigger Conditions:
- User initiates procurement actions in areas without network connectivity (remote sites, underground, shielded areas)
- Configuring offline-first architecture for the procurement system
- Setting up intelligent queuing and background synchronization
- Resolving conflicts between offline changes and online data
- Verifying data integrity after synchronization
Prerequisites:
- Offline-first app installed on device
- Initial data cached before going offline
- Local storage available for queuing offline actions
Step-by-Step Procedure
Step 1: Offline Detection and Adaptation
Detect network disconnection and adapt procurement workflows:
| Detection Method |
Adaptation Action |
| No network response to API call |
Switch to offline mode, display offline indicator |
| Network quality degraded |
Queue non-critical requests, proceed with critical offline |
| User manually enables offline mode |
Force offline mode with clear status indicator |
Step 2: Offline-First Data Caching and Prioritization
Cache critical procurement data for offline access, prioritized by importance:
| Priority |
Data Category |
Cached Fields |
Reason for Priority |
| P0 (Critical) |
Project/WBS Data |
Project name, WBS codes, cost codes, budget per WBS |
Required for order creation and validation |
| P0 (Critical) |
Supplier Data |
Supplier name, code, tier, status, contact, approved items |
Required for supplier selection and matching |
| P0 (Critical) |
Template Data |
Template name, fields, validation rules, required sections |
Required for order form generation |
| P1 (High) |
Catalog Data |
Item code, description, specification, unit price |
Required for standard item selection |
| P1 (High) |
Approval Rules |
Thresholds, approver assignments, routing types |
Required for approval routing configuration |
| P2 (Medium) |
Order History |
Recent orders, status, SO acknowledgments |
Required for reference and duplicate checking |
| P3 (Low) |
Analytics Data |
Dashboards, KPIs, trends |
Not critical offline, sync on reconnect |
Step 3: Intelligent Queuing and Background Synchronization
Queue offline actions for processing when connectivity is restored:
| Action Type |
Queue Priority |
Sync Timing |
Conflict Risk |
| Order Creation/Modification |
HIGH |
Immediately on reconnect |
HIGH (order may be modified by another user) |
| Approval Actions |
HIGH |
Immediately on reconnect |
MEDIUM (approval authority must be verified) |
| SO Acknowledgment |
MEDIUM |
Within 5 minutes of reconnect |
LOW |
| GRN Recording |
HIGH |
Immediately on reconnect |
HIGH (GRN may affect payment processing) |
| Supplier Rating/Feedback |
LOW |
Background sync (within 30 minutes) |
LOW |
| Template Updates |
LOW |
Background sync (within 30 minutes) |
MEDIUM |
Step 4: Conflict Resolution for Concurrent Changes
Resolve conflicts when offline changes conflict with online data:
| Conflict Type |
Resolution Strategy |
| Order modified offline and another user modified the same order online |
Server wins — offline changes are discarded user notified and asked to re-apply |
| GRN recorded offline, but order already closed online |
Conflict flagged — offline GRN held for manual review by procurement team |
| Supplier tier changed online, but offline change used old tier |
Server wins — offline change reconciled with current supplier tier |
| Budget reduced online, offline order would exceed new budget |
Conflict flagged — order held for approval until budget increased or order value reduced |
| Template updated online, offline form used old version |
Conflict resolved gracefully — offline changes preserved, new template version applied on sync with field mapping |
Step 5: Data Integrity Verification
Verify data integrity after offline synchronization:
| Integrity Check |
Method |
Expected Result |
| Record Count Match |
Count of offline-created orders vs. online records after sync |
Counts match — all orders synced successfully |
| Data Field Completeness |
Verify all fields of synced records populated |
No null or empty fields |
| Referential Integrity |
Verify all WBS codes, supplier codes, and template IDs valid |
All references resolve |
| Sequence Number Continuity |
Verify order numbers, GRN numbers, and SO numbers sequential |
Gaps flagged and investigated |
| Audit Trail Completeness |
Verify all approvals, changes, and actions recorded in audit log |
Audit log matches actions |
Step 6: Offline Approval Processing
Process approvals when approver is offline:
- Capture approver name, decision, timestamp, and GPS coordinates
- Store approval record locally with cryptographic signature
- Verify GPS coordinates match project site or office location
- Queue approval for synchronization when connectivity restored
- After sync, notify order owner of approval decision
Step 7: Offline Synchronization and Reconnection
When connectivity is restored:
- Detect Connectivity: Monitor for network restoration
- Prioritize Sync Queue: Process HIGH priority queues first
- Execute Sync: Send queued actions to server
- Resolve Conflicts: Apply resolution strategies for conflicts
- Notify User: Inform user of sync results and any actions requiring attention
- Cache Update: Update local cache with latest server data
- Switch to Online Mode: Resume normal online operations if connectivity is stable
Success Criteria
Common Pitfalls
- Stale Data — Offline data is only as fresh as the last cache. If going offline for an extended period, critical data (budget, supplier tiers, approval authorities) may be outdated. Warn users before they use potentially stale data.
- Lost Offline Actions — If the device crashes or the app is killed before queued actions are synced, the actions are lost. Ensure queued actions are persisted to durable local storage and survive app restarts.
- Conflict Storm — If many users were making offline changes to the same records, synchronization will trigger many conflicts. Prioritize resolution and avoid creating conflicts that cascade.
- Data Size Limits — Caching too much data for offline use can cause mobile storage exhaustion. Keep cache under 500MB — prioritize P0/P1 data, exclude P3 analytics.
- Security Exposure — Offline data is stored on the device and may be accessible if the device is lost or stolen. Encrypt all cached procurement data and require device PIN/biometric authentication for app access.
Cross-References
Related Skills
procurement-order-management — Offline orders use the same workflow with local processingapproval-routing — Offline approvals queued and synced with routing rulesgps-approval-configuration — Offline approvals capture GPS coordinates locallyvoice-command-integration — Voice orders can be created offline and queued for sync
Related Agents
Mobile Workflow Designer (DomainForge) — Offline workflow architecture and UX designMobile Testing Specialist (DomainForge) — Offline functionality and synchronization testingMobile API Integration Specialist (InfraForge) — Offline sync API and conflict resolution
Example Usage
Scenario: Field worker creates emergency order and records GRN while underground with no connectivity
- Offline Detection: App detects no connectivity → switches to offline mode with indicator
- Data Available: Critical data cached — project ABC, WBS codes, supplier list, templates
- Order Creation: User creates WO for emergency excavation using offline form — order queued as HIGH priority
- GRN Recording: User records GRN for materials received — GRN queued as HIGH priority
- Reconnection: When user returns to surface and connectivity is restored, sync queue is processed — order created, GRN recorded, both matched to online records
- User Notification: App notifies "2 actions synced successfully: WO-2026-0912 created, GRN-2026-0445 recorded"
1---2name: procurement-offline3description: Implement offline-first procurement architecture with intelligent queuing, background synchronization, conflict resolution, and data integrity verification4---56# Offline Procurement Operations78## Overview910Implement offline-first procurement architecture with intelligent caching, prioritized data storage, queuing, background synchronization, conflict resolution for concurrent changes, and data integrity verification. Enables complete procurement functionality without network connectivity.1112**Announce at start:** "I'm using the offline-procurement skill to configure or execute offline procurement operations."1314## When to Use This Skill1516**Trigger Conditions:**17- User initiates procurement actions in areas without network connectivity (remote sites, underground, shielded areas)18- Configuring offline-first architecture for the procurement system19- Setting up intelligent queuing and background synchronization20- Resolving conflicts between offline changes and online data21- Verifying data integrity after synchronization2223**Prerequisites:**24- Offline-first app installed on device25- Initial data cached before going offline26- Local storage available for queuing offline actions2728## Step-by-Step Procedure2930### Step 1: Offline Detection and Adaptation3132Detect network disconnection and adapt procurement workflows:3334| Detection Method | Adaptation Action |35|-----------------|-------------------|36| No network response to API call | Switch to offline mode, display offline indicator |37| Network quality degraded | Queue non-critical requests, proceed with critical offline |38| User manually enables offline mode | Force offline mode with clear status indicator |3940### Step 2: Offline-First Data Caching and Prioritization4142Cache critical procurement data for offline access, prioritized by importance:4344| Priority | Data Category | Cached Fields | Reason for Priority |45|----------|--------------|---------------|---------------------|46| P0 (Critical) | Project/WBS Data | Project name, WBS codes, cost codes, budget per WBS | Required for order creation and validation |47| P0 (Critical) | Supplier Data | Supplier name, code, tier, status, contact, approved items | Required for supplier selection and matching |48| P0 (Critical) | Template Data | Template name, fields, validation rules, required sections | Required for order form generation |49| P1 (High) | Catalog Data | Item code, description, specification, unit price | Required for standard item selection |50| P1 (High) | Approval Rules | Thresholds, approver assignments, routing types | Required for approval routing configuration |51| P2 (Medium) | Order History | Recent orders, status, SO acknowledgments | Required for reference and duplicate checking |52| P3 (Low) | Analytics Data | Dashboards, KPIs, trends | Not critical offline, sync on reconnect |5354### Step 3: Intelligent Queuing and Background Synchronization5556Queue offline actions for processing when connectivity is restored:5758| Action Type | Queue Priority | Sync Timing | Conflict Risk |59|-------------|---------------|-------------|---------------|60| Order Creation/Modification | HIGH | Immediately on reconnect | HIGH (order may be modified by another user) |61| Approval Actions | HIGH | Immediately on reconnect | MEDIUM (approval authority must be verified) |62| SO Acknowledgment | MEDIUM | Within 5 minutes of reconnect | LOW |63| GRN Recording | HIGH | Immediately on reconnect | HIGH (GRN may affect payment processing) |64| Supplier Rating/Feedback | LOW | Background sync (within 30 minutes) | LOW |65| Template Updates | LOW | Background sync (within 30 minutes) | MEDIUM |6667### Step 4: Conflict Resolution for Concurrent Changes6869Resolve conflicts when offline changes conflict with online data:7071| Conflict Type | Resolution Strategy |72|---------------|---------------------|73| Order modified offline and another user modified the same order online | Server wins — offline changes are discarded user notified and asked to re-apply |74| GRN recorded offline, but order already closed online | Conflict flagged — offline GRN held for manual review by procurement team |75| Supplier tier changed online, but offline change used old tier | Server wins — offline change reconciled with current supplier tier |76| Budget reduced online, offline order would exceed new budget | Conflict flagged — order held for approval until budget increased or order value reduced |77| Template updated online, offline form used old version | Conflict resolved gracefully — offline changes preserved, new template version applied on sync with field mapping |7879### Step 5: Data Integrity Verification8081Verify data integrity after offline synchronization:8283| Integrity Check | Method | Expected Result |84|----------------|--------|-----------------|85| Record Count Match | Count of offline-created orders vs. online records after sync | Counts match — all orders synced successfully |86| Data Field Completeness | Verify all fields of synced records populated | No null or empty fields |87| Referential Integrity | Verify all WBS codes, supplier codes, and template IDs valid | All references resolve |88| Sequence Number Continuity | Verify order numbers, GRN numbers, and SO numbers sequential | Gaps flagged and investigated |89| Audit Trail Completeness | Verify all approvals, changes, and actions recorded in audit log | Audit log matches actions |9091### Step 6: Offline Approval Processing9293Process approvals when approver is offline:94951. Capture approver name, decision, timestamp, and GPS coordinates962. Store approval record locally with cryptographic signature973. Verify GPS coordinates match project site or office location984. Queue approval for synchronization when connectivity restored995. After sync, notify order owner of approval decision100101### Step 7: Offline Synchronization and Reconnection102103When connectivity is restored:1041051. **Detect Connectivity**: Monitor for network restoration1062. **Prioritize Sync Queue**: Process HIGH priority queues first1073. **Execute Sync**: Send queued actions to server1084. **Resolve Conflicts**: Apply resolution strategies for conflicts1095. **Notify User**: Inform user of sync results and any actions requiring attention1106. **Cache Update**: Update local cache with latest server data1117. **Switch to Online Mode**: Resume normal online operations if connectivity is stable112113## Success Criteria114115- [ ] Offline detection functioning reliably and adaptation triggers correctly116- [ ] Critical data (P0/P1) available offline for procurement operations117- [ ] Offline actions queued correctly with appropriate priority118- [ ] Background synchronization processes all queued actions on reconnect119- [ ] Conflict resolution handles all 5 conflict types correctly120- [ ] Data integrity verification passes all 5 checks after synchronization121- [ ] Offline approvals processed and synced with complete audit trail122- [ ] User notification provided for all sync issues requiring manual intervention123124## Common Pitfalls1251261. **Stale Data** — Offline data is only as fresh as the last cache. If going offline for an extended period, critical data (budget, supplier tiers, approval authorities) may be outdated. Warn users before they use potentially stale data.1272. **Lost Offline Actions** — If the device crashes or the app is killed before queued actions are synced, the actions are lost. Ensure queued actions are persisted to durable local storage and survive app restarts.1283. **Conflict Storm** — If many users were making offline changes to the same records, synchronization will trigger many conflicts. Prioritize resolution and avoid creating conflicts that cascade.1294. **Data Size Limits** — Caching too much data for offline use can cause mobile storage exhaustion. Keep cache under 500MB — prioritize P0/P1 data, exclude P3 analytics.1305. **Security Exposure** — Offline data is stored on the device and may be accessible if the device is lost or stolen. Encrypt all cached procurement data and require device PIN/biometric authentication for app access.131132## Cross-References133134### Related Skills135- `procurement-order-management` — Offline orders use the same workflow with local processing136- `approval-routing` — Offline approvals queued and synced with routing rules137- `gps-approval-configuration` — Offline approvals capture GPS coordinates locally138- `voice-command-integration` — Voice orders can be created offline and queued for sync139140### Related Agents141- `Mobile Workflow Designer` (DomainForge) — Offline workflow architecture and UX design142- `Mobile Testing Specialist` (DomainForge) — Offline functionality and synchronization testing143- `Mobile API Integration Specialist` (InfraForge) — Offline sync API and conflict resolution144145## Example Usage146147**Scenario:** Field worker creates emergency order and records GRN while underground with no connectivity1481491. **Offline Detection:** App detects no connectivity → switches to offline mode with indicator1502. **Data Available:** Critical data cached — project ABC, WBS codes, supplier list, templates1513. **Order Creation:** User creates WO for emergency excavation using offline form — order queued as HIGH priority1524. **GRN Recording:** User records GRN for materials received — GRN queued as HIGH priority1535. **Reconnection:** When user returns to surface and connectivity is restored, sync queue is processed — order created, GRN recorded, both matched to online records1546. **User Notification:** App notifies "2 actions synced successfully: WO-2026-0912 created, GRN-2026-0445 recorded"
Construct-AI-primary