## Sheet: Template Info Sheet: Template Info ==================== [GAP: Missing data for Sheet: Template Info] ## Sheet: Scope Filters # Sheet: Scope Filters ## 1. Introduction This section defines the scope filters for the system, specifying functional, data, and architectural boundaries as required by ISO-29148. Scope filters clarify what is explicitly included and excluded from the system’s requirements, based solely on the current system’s capabilities and constraints. --- ## 2. Functional Scope Filters The current system imposes strict limitations on order management, payment, and notification functionalities. The following table summarizes the main functional scope filters: | ID | Limitation | Impact Area | Severity | |---------|---------------------------------------------------------------------------------------------------------------------|----------------------|----------| | LIM-001 | **Order creation is single-entry only.** No bulk or batch order creation capability exists. Orders can only be created one at a time via the REST API. | Order Service | High | | LIM-002 | **No CSV/file-based order import functionality.** There is no endpoint or mechanism to upload and process order data from files (CSV, Excel, etc.). | Order Service | High | | LIM-003 | **Payment processing handles one transaction at a time.** No batch payment API exists. Each order requires an individual payment API call. | Payment Service | High | | LIM-004 | **Notifications are sent individually per order.** No bulk notification capability exists. Each notification requires a separate API call. | Notification Service | Medium | | LIM-005 | **Cross-service calls are sequential.** Order creation flow (Order → Payment → Notification) executes sequentially. No parallel processing of payment and notification. | All Services | Medium | | LIM-006 | **No progress tracking for batch operations.** The system has no mechanism to track progress of multi-item operations because no batch operations exist. | All Services | Medium | *Source: [KB-146a6a29-932f-485d-96d6-6a92ee610336]* --- ## 3. Data Scope Filters ### 3.1 Orders Table Schema Constraints The system does not support any data model for batch or group import of orders. The following schema limitations are enforced: | Constraint | Description | |-------------------------------|----------------------------------------------------------------------------------------------| | No batch_id column | Cannot group orders by import batch | | No csv_source field | Cannot trace the source CSV file for imported orders | | No bulk_import_group column | No correlation between orders from the same import | | 1:1 unique constraint on order_id in payments | Prevents batch payment grouping; each payment is linked to a single order only | *Source: [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2]* --- ## 4. Architectural Scope Filters - **No Bulk Import UI:** The frontend does not provide any user interface for CSV upload, drag-and-drop, or batch order creation. The CSV Import button is disabled and labeled as “CSV Import (Not Implemented)”. *Source: [KB-16181d30-2dd3-421e-bab0-939cd85255d2], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]* - **No Bulk/Batched APIs:** All order, payment, and notification APIs operate on a single resource per call. There are no endpoints for bulk or batch processing. *Source: [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0d7daadd-e958-4592-900a-55db91f8aa55]* - **Sequential Processing Only:** All cross-service operations (order creation, payment, notification) are executed sequentially. There is no parallel or asynchronous processing, and no message broker or event bus is present in the architecture. *Source: [KB-0d7daadd-e958-4592-900a-55db91f8aa55], [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf]* - **No Progress Tracking for Batch Operations:** Since batch operations are not supported, there is no mechanism for tracking progress or partial failures for multi-item operations. *Source: [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]* --- ## 5. Out-of-Scope Features The following features are explicitly out of scope for the current system: - Bulk or batch order creation (via UI or API) - CSV or file-based order import - Batch payment processing (aggregated or grouped payments) - Bulk notification sending - Progress tracking for batch operations - Parallel or asynchronous cross-service processing --- ## 6. Summary The system’s scope is strictly limited to single-order, single-payment, and single-notification operations, with all processing performed sequentially and no support for batch or bulk features at any layer (UI, API, or data model). Any requirements for bulk import, batch processing, or related progress/error tracking are outside the current system’s scope and would require significant architectural changes. --- **End of Scope Filters** ## Sheet: Sections # Sheet: Sections This section outlines the functional and constraint requirements for order, payment, and notification processing within the current system, as well as the architectural limitations impacting batch operations and CSV import capabilities. ## 1. Order Creation and Management ### 1.1 Functional Requirements - Orders can only be created one at a time via the REST API. There is no capability for bulk or batch order creation. Each order must be submitted individually ([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]). - No CSV/file-based order import functionality exists. There is no endpoint or mechanism to upload and process order data from files (CSV, Excel, etc.) ([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]). - The Order Management interface displays a disabled CSV Import button and a BulkImportBanner warning that CSV import is not available ([KB-16181d30-2dd3-421e-bab0-939cd85255d2]). ### 1.2 Data Model Constraints - The orders table does not have batch_id, csv_source, or bulk_import_group columns. There is no mechanism to track which orders belong to a batch import ([KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8], [KB-02c65582-456a-4ffe-8f7b-7d37af08e656]). - Each payment record is linked 1:1 with an order_id and cannot be grouped for batch processing ([KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]). ## 2. Payment Processing - Payment processing handles one transaction at a time. No batch payment API exists. Each order requires an individual payment API call ([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]). - Maximum payment amount per transaction is 1,000,000 JPY ([KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]). - There is no capability to aggregate multiple order amounts into a single transaction ([KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]). ## 3. Notification Processing - Notifications are sent individually per order. No bulk notification capability exists. Each notification requires a separate API call ([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8]). - Notification Service rate limit is 10 requests per second. Sending notifications for 10,000 orders requires a minimum of 1,000 seconds (~17 minutes) ([KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8], [KB-04a84995-0820-4319-cd1582821058a]). ## 4. Processing Flow and Architectural Constraints - Order creation, payment processing, and notification sending are executed sequentially, not in parallel. The total latency for order creation is the sum of save, payment, and notification times ([KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]). - There is no retry or circuit breaker mechanism for cross-service calls. Failures are logged but not retried ([KB-01305cb3-d331-4b4b-ba02-69ada467b41d], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]). - No progress tracking mechanism exists for batch operations, as batch operations are not supported ([KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]). ## 5. User Interface Limitations - No bulk order import UI is available. There is no CSV upload, drag-and-drop, or batch creation form ([KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]). - Dashboard statistics are computed client-side only. There is no backend endpoint for list-all or aggregation ([KB-017cfb36-5c85-4f93-92bd-6bb395022c54]). - No real-time updates are available; polling is used instead of WebSocket ([KB-017cfb36-5c85-4f93-92bd-6bb395022c54]). ## 6. Summary Table of System Limitations | ID | Limitation | Impact Area | Severity | |---------|-------------------------------------------------------------------------------------------------------------|----------------------|------------| | LIM-001 | Order creation is single-entry only. No bulk or batch order creation capability exists. | Order Service | High | | LIM-002 | No CSV/file-based order import functionality. No endpoint for file upload and processing. | Order Service | High | | LIM-003 | Payment processing handles one transaction at a time. No batch payment API exists. | Payment Service | High | | LIM-004 | Notifications are sent individually per order. No bulk notification capability exists. | Notification Service | Medium | | LIM-005 | Cross-service calls are sequential. No parallel processing of payment and notification. | All Services | Medium | | LIM-006 | No progress tracking for batch operations. No mechanism to track progress of multi-item operations. | All Services | Medium | ([KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]) --- This section is compliant with ISO-29148 structural requirements and references only the provided context. No external information has been included.