Oracle Fusion Scrap Quantity Test Cases
Validate recording of scrap quantity against work orders and operations in Oracle Fusion SCM Manufacturing, including reason code capture and cost impact recognition, without assuming scrap is always chargeable to the same cost account.
| Test ID | ORCL.SCM.MFG.COMP.SCRAP |
| Application | Oracle Fusion Cloud |
| Product | SCM |
| Module | Manufacturing |
| Process | Scrap Quantity |
| Business Flow | Plan-to-Produce |
| Scenario Type | Positive / Functional |
| Test Usage | Functional Testing / Regression Testing / UAT |
| Priority | High |
| Automation | SyntraFlow Ready |
| Library | Syntra Standard |
Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions automatically while presenting the scenario as business-readable test steps for documentation, review and reporting. This scenario is presented as 6 business-readable test steps; SyntraFlow's automation executes approximately 13 underlying Oracle Fusion UI actions to complete it.
Test Objective
The objective of this test is to validate recording of scrap quantity against work orders and operations in Oracle Fusion SCM Manufacturing, including reason code capture and cost impact recognition.
The scenario should confirm that:
- scrap quantity is correctly recorded against a work order when recorded at the work order level
- scrap quantity is correctly recorded against an operation when recorded at the operation level
- a scrap reason code is correctly captured and associated with the scrap transaction, where a reason is required
- partial and full scrap quantities are correctly recorded, including remaining-quantity impact
- the resulting cost impact is correctly recognized in the associated cost account, as configured for the manufacturing organization
- Oracle correctly enforces validation and security restrictions when scrap quantity exceeds available quantity, a required reason is missing, or an unauthorized user attempts scrap entry (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION)
This scenario covers scrap quantity recording in Oracle Fusion SCM Manufacturing TEST/UAT environments, at both the work order and operation level. The cost account to which scrap is charged is governed by manufacturing organization cost accounting configuration — this scenario does not assume scrap is always chargeable to the same cost account across Oracle Fusion implementations. It does not cover full or partial work order completion, which are covered by the separate Complete Work Order and Partial Completion scenarios in the same Manufacturing Completions test library.
When to Use This Test
- Functional testing of scrap quantity recording for a new Oracle Fusion SCM Manufacturing implementation
- Regression testing of work order-level and operation-level scrap recording after an Oracle quarterly update
- UAT sign-off for production operators and supervisors who record scrap during production
- Validating that scrap quantity exceeding available quantity and missing scrap reasons are correctly blocked or flagged
- Diagnosing DATA_ERROR, CONFIGURATION_ERROR and SECURITY_ERROR conditions surfaced during scrap entry before escalating as a possible APPLICATION_ERROR
Where This Test Fits in the Manufacturing Completions Process
Scrap Quantity is the third and final stage of the Completions scenario family within Plan-to-Produce, following Partial Completion. Exact scrap cost account, reason code requirement and available-quantity handling depend on manufacturing organization parameters, cost accounting setup and customer-specific Oracle Fusion configuration.
Preconditions
- The work order or operation to be scrapped against exists in Oracle Fusion SCM Manufacturing with a status eligible for scrap entry.
- A valid scrap reason code is configured and available for selection, or deliberately omitted for negative scenarios.
- The available quantity for scrap is known and, for boundary scenarios, deliberately set at or below the intended scrap quantity.
- The test user has appropriate access to record scrap for the manufacturing organization, or deliberately lacks it for negative scenarios.
- The cost account associated with scrap transactions is configured for the manufacturing organization per customer-specific setup.
Exact field availability, reason code requirements and cost account behavior may vary by Oracle Fusion implementation, manufacturing organization parameters and customer-specific configuration. The cost account to which scrap is charged should not be assumed to be a single universal account across implementations.
Sample Test Data
| Work Order | ${WORK_ORDER} |
| Operation | ${OPERATION} |
| Scrap Quantity | ${SCRAP_QUANTITY} |
| Scrap Reason | ${SCRAP_REASON} |
| Available Quantity | ${AVAILABLE_QUANTITY} |
| Cost Impact | ${COST_IMPACT} |
Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion SCM TEST/UAT environment. Scrap reason requirements and cost account mapping depend on manufacturing organization configuration.
Test Steps
6 business-readable steps. SyntraFlow's automation executes ~13 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.
| # | User Action | Expected Result |
|---|---|---|
| 1 | Sign In and Navigate to Manufacturing Sign in to Oracle Fusion using an authorised manufacturing test user and navigate to the Manufacturing work area. | The Manufacturing work area opens successfully. |
| 2 | Navigate to the Work Order or Operation Open the work order or the specific operation against which scrap quantity will be recorded. ${WORK_ORDER} / ${OPERATION} | The work order or operation details page opens with the correct status and available quantity. |
| 3 | Select the Scrap Action Select the scrap action at the intended level, either work order or operation. | The scrap entry page opens at the correct level. |
| 4 | Enter Scrap Quantity and Reason Code Enter the scrap quantity and select a scrap reason code where required. ${SCRAP_QUANTITY} / ${SCRAP_REASON} This single business step replaces multiple technical actions such as opening the scrap fields, entering the quantity and selecting a reason code from a list of values. | The scrap quantity and reason code are accepted, or the expected blocking validation is shown for negative scenarios. |
| 5 | Submit the Scrap Transaction Submit the scrap transaction for the selected work order or operation. | Oracle Fusion successfully processes the scrap transaction without unexpected errors, or correctly returns a blocking validation for negative scenarios. |
| 6 | Verify Resulting Quantity, Cost Impact and Audit TrailBusiness assertion Reopen or refresh the work order or operation and confirm the resulting quantity, cost impact and audit trail. ${COST_IMPACT} This is the primary business assertion for the scenario — scrap quantity, cost impact and audit trail correctly reflecting the transaction is the expected pass condition, not merely a successful save. | The scrap quantity, remaining available quantity, cost impact and audit trail are all correctly reflected. |
Expected Results
- Scrap quantity is correctly recorded at the selected level, whether work order or operation.
- The scrap reason code is correctly captured where required.
- The resulting cost impact is correctly recognized in the associated cost account.
- Scrap quantity exceeding the available quantity is correctly blocked or flagged.
- A scrap transaction missing a required reason is correctly blocked.
- Unauthorized scrap entry is correctly blocked.
Key Validation Checkpoints
- Scrap quantity correctly recorded at the selected level (work order or operation).
- Reason code correctly captured.
- Cost impact correctly recognized in the associated cost account.
- Scrap exceeding available quantity correctly blocked or flagged.
- Missing reason correctly blocked where required.
- Unauthorized scrap entry correctly blocked.
Go Beyond the Standard Test with Jarvis AI
The Syntra Standard Test Library defines the core Scrap Quantity business scenario. Jarvis AI can extend this scenario by generating additional level, reason-code, quantity-boundary, cost-impact and security variations using customer-specific test data and configuration available through Syntra DataVault.
Teams do not need to manually build a separate test for every scrap level, reason code or quantity boundary combination. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative, Boundary and Security variations for the customer's environment — including scrap quantity exceeding available quantity and unauthorized scrap entry attempts, since correctly enforced validation and security around scrap is an important part of what this scenario proves.
From Standard Test to Executed Regression Pack
Rather than maintaining a separate test page for every possible scrap level, reason code, quantity boundary or security combination, SyntraFlow maintains one core Scrap Quantity scenario and allows Jarvis AI to generate level, reason-code and security-specific variations using the customer's available test data.
AI-Generated Test Variations
The same Scrap Quantity business scenario can produce many test variations without creating separate public library pages. Below is a real slice of SyntraFlow's Build Scripts library, filtered to SCM Manufacturing.
- Record scrap quantity at the work order level
- Record scrap quantity at the operation level
- Record scrap quantity with a reason code
- Record partial and full scrap quantity
- Verify scrap cost impact recognized in the associated cost account
- Attempt to record scrap quantity exceeding the available quantity
- Attempt to submit a scrap transaction without a required scrap reason
- Attempt scrap entry by a user without scrap privileges for the manufacturing organization
These are representative examples only. Negative-scenario behavior, available field combinations and cost account mapping can depend on the customer's Oracle Fusion configuration, controls and security — not every Oracle configuration behaves identically.
Generated Using Your DataVault Test Data
Generic test data rarely represents every work order, operation, scrap reason and cost account combination in a real Oracle Fusion SCM Manufacturing environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Scrap Quantity scenarios relevant to the customer's actual implementation.
Standard Library Definition
Work Order ${WORK_ORDER}
Operation ${OPERATION}
Scrap Quantity ${SCRAP_QUANTITY}
Scrap Reason ${SCRAP_REASON}
Available Quantity ${AVAILABLE_QUANTITY}
Cost Impact ${COST_IMPACT}
DataVault
Work Orders Eligible work orders and operations by manufacturing organization Scrap Reasons Configured scrap reason codes by organization Cost Accounts Scrap cost account mapping per manufacturing organization User Roles Configured scrap entry privileges by role and organization
Jarvis AI Generates
Scenario 01 — Record Scrap at Work Order Level Scenario 02 — Record Scrap at Operation Level Scenario 03 — Record Scrap with Reason Code Scenario 04 — Record Partial Scrap Quantity Scenario 05 — Verify Scrap Cost Impact Scenario 06 — Scrap Quantity Exceeding Available Quantity ...
Scrap Quantity test data can include sensitive manufacturing categories such as work order, operation and cost account information. The public Syntra Standard Test Library uses illustrative placeholder data only. Where DataVault is connected, customer-specific work order and scrap data used in testing are masked and synthetic, remaining within the customer's controlled SyntraFlow environment and access model, protected according to DataVault's data masking policies. See /datavault/data-masking/ for details.
Example Test Variations
9 individual Scrap Quantity test scenarios spanning work order and operation-level scrap recording, reason codes, cost impact and negative/security scrap testing.
| ID | Variation | Type | Key Difference | Execution |
|---|---|---|---|---|
| MFG-SCRAP-001 | Record Scrap at Work Order Level | Positive | Scrap quantity ${SCRAP_QUANTITY} is recorded against work order ${WORK_ORDER} at the work order level. | SyntraFlow Ready |
| MFG-SCRAP-002 | Record Scrap at Operation Level | Positive | Scrap quantity ${SCRAP_QUANTITY} is recorded against operation ${OPERATION} within work order ${WORK_ORDER}. | SyntraFlow Ready |
| MFG-SCRAP-003 | Record Scrap with Reason Code | Positive | Scrap quantity ${SCRAP_QUANTITY} is recorded against work order ${WORK_ORDER} with reason code ${SCRAP_REASON} captured. | SyntraFlow Ready |
| MFG-SCRAP-004 | Record Partial Scrap Quantity | Positive | A partial scrap quantity ${SCRAP_QUANTITY}, less than available quantity ${AVAILABLE_QUANTITY}, is recorded against work order ${WORK_ORDER}. | SyntraFlow Ready |
| MFG-SCRAP-005 | Record Full Scrap Quantity | Positive | The full available quantity ${AVAILABLE_QUANTITY} is recorded as scrap quantity ${SCRAP_QUANTITY} against work order ${WORK_ORDER}. | SyntraFlow Ready |
| MFG-SCRAP-006 | Verify Scrap Cost Impact | Positive | Cost impact ${COST_IMPACT} resulting from scrap quantity ${SCRAP_QUANTITY} is verified in the associated cost account as configured. | SyntraFlow Ready |
| MFG-SCRAP-007 | Scrap Quantity Exceeding Available Quantity | Negative/Boundary | Scrap quantity ${SCRAP_QUANTITY} exceeding available quantity ${AVAILABLE_QUANTITY} on work order ${WORK_ORDER} is correctly blocked or flagged. | SyntraFlow Ready |
| MFG-SCRAP-008 | Missing Scrap Reason | Negative | A scrap transaction for work order ${WORK_ORDER} submitted without scrap reason ${SCRAP_REASON} is correctly blocked where a reason is required. | SyntraFlow Ready |
| MFG-SCRAP-009 | Unauthorized Scrap Entry | Negative/Security | An unauthorized user attempts to record scrap quantity ${SCRAP_QUANTITY} against work order ${WORK_ORDER} and is correctly denied. | SyntraFlow Ready |
No variations match this filter.
Automatically Expand Positive and Negative Scrap Coverage
Positive Testing
Jarvis generates scenarios using work order, operation, quantity and reason-code combinations expected to record scrap successfully in Oracle Fusion Manufacturing.
Valid Work Order + Valid Scrap Quantity Within Available Quantity + Reason Code Provided → Scrap Recorded
Negative Testing
Jarvis can also generate scenarios designed to exercise Oracle's validations around scrap quantity, reason code requirements and scrap entry security.
- Scrap Quantity Exceeds Available Quantity → Expected Status Validation
- Missing Scrap Reason → Expected Status Validation
- Unauthorized User → Expected Access Restriction
A negative manufacturing scenario passes when Oracle correctly enforces the expected data, configuration or security rule
| Scenario | Oracle Outcome | Test Result |
|---|---|---|
| Valid work order data | Work order created | PASS |
| Invalid item or work definition | Validation occurs | PASS |
| Component shortage | Validation or warning occurs | PASS |
| Unauthorized user | Access prevented | PASS |
| Unexpected application exception | Unexpected failure | FAIL |
Turn AI-Generated Variations into a Regression Pack
Users can select generated Scrap Quantity scenarios and group them into reusable execution packs.
SCM Manufacturing Scrap Quantity Regression Pack
- Record Scrap at Work Order Level
- Record Scrap at Operation Level
- Record Scrap with Reason Code
- Record Partial Scrap Quantity
- Record Full Scrap Quantity
- Verify Scrap Cost Impact
- Scrap Quantity Exceeding Available Quantity
- Missing Scrap Reason
- Unauthorized Scrap Entry
Run On-Demand or Schedule Automated Batch Execution
SyntraFlow can execute selected Scrap Quantity scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.
Once scheduled, SyntraFlow executes the selected Scrap Quantity scenarios unattended and records the outcome of each test and business assertion.
| Pack | SCM Manufacturing Scrap Quantity Regression Pack |
| Schedule | Quarterly Update Regression |
| Tests | 9 scenarios |
| Execution | Batch Mode |
| Start | 10:00 PM |
| Environment | Oracle Fusion TEST |
| Status | Scheduled |
Illustrative example — not a live schedule.
Review Results Across the Entire Test Pack
Users can drill from the regression pack into a scenario, its business steps, the underlying automation actions, and the evidence captured for each.
Illustrative example data — not actual production metrics.
Regression Pack → Scenario → Business Step → Automation Action → Evidence
Security & Scrap Variations
Access to record scrap quantity for a given manufacturing organization is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that scrap entry access behaves as expected for each role — not to assert a single universal Oracle security model.
| Persona | Action | Expected | Syntra Result |
|---|---|---|---|
| Production Operator | Record Scrap at Operation Level | Allowed | PASS |
| Production Supervisor | Record Scrap at Work Order Level | Allowed | PASS |
| Unauthorized User | Attempts to Record Scrap Quantity | Access prevented | PASS |
Understand Why a Test Failed
SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.
From Business Scenario to Execution Evidence
Business teams get readable test documentation; automation teams retain detailed execution traceability.
Meet Jarvis — SyntraFlow's AI Testing Engine
Jarvis extends the Syntra Standard Test Library by analysing the Scrap Quantity scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary and Security coverage for the customer's environment.
How SyntraFlow Automates This Test
The Standard Test defines the scenario; DataVault, Jarvis AI and SyntraFlow's execution engine take it from a single reusable business definition to executed, evidenced regression coverage.
Business Step → Underlying UI Actions
What SyntraFlow Captures Per Run
Action Status vs. Business Validation
A successful UI interaction does not automatically prove the scrap quantity was correctly recorded and costed — this is illustrative of how SyntraFlow separates action success from business validation; it does not reflect a specific live execution. When a step fails, SyntraFlow's evidence trail is designed to help a tester classify the likely cause — for example DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: Scrap Entry Failed — Likely category: EXPECTED_VALIDATION — Evidence: Scrap quantity ${SCRAP_QUANTITY} exceeds available quantity ${AVAILABLE_QUANTITY} — Recommendation: Confirm scrap quantity does not exceed the available balance. A failure should never be labeled as an Oracle defect without eliminating data, configuration, security, automation and integration causes first.
| Step | Action Status | Business Validation |
|---|---|---|
| Select the Scrap Action | Pass | — |
| Submit the Scrap Transaction | Pass | — |
| Verify Resulting Quantity, Cost Impact and Audit Trail | Pass | Pass |
Related Manufacturing Tests
Scrap Quantity is the final stage of the Completions cluster — explore the related completion, operation and exception-handling scenarios below.
Turn This Standard Test into Your Oracle SCM Scrap Quantity Regression Suite
Start with the Syntra Standard Scrap Quantity test, use DataVault to provide environment-specific test data, let Jarvis generate additional level, reason-code, boundary and security variations, and execute the resulting regression pack automatically with SyntraFlow.
Use This Oracle Fusion Test Case
Download Test Case
Excel, CSV or JSON export.
Coming soonAutomate with SyntraFlow
Run this script against your own tenant today.