{
  "test_id": "ORCL.P2P.PROC.RCV.EXCEPTION",
  "scenario_name": "Receiving Exceptions",
  "application": "Oracle Fusion Cloud",
  "product": "SCM / Procurement",
  "module": "Procurement",
  "process": "Receiving",
  "business_flow": "Procure-to-Pay",
  "scenario_type": "Negative / Exception Handling",
  "priority": "High",
  "automation_status": "SyntraFlow Ready",
  "library": "Syntra Standard",
  "canonical_url": "https://www.syntraflow.cloud/oracle-erp-testing-tool/test-library/scm/procurement/receiving/receiving-exceptions/",
  "objective": {
    "intro": "Validate receiving business rules and exception handling for invalid or incomplete receipt conditions across the purchase order, quantity, item/organization and dates/configuration exception categories.",
    "confirms": [
      "the deliberately invalid PO, quantity, item/organization or dates/configuration condition is correctly rejected or flagged rather than silently accepted",
      "the resulting exception, error or validation message matches the expected classification for the exception category triggered",
      "the receipt status correctly reflects the unresolved exception rather than indicating a successful receipt",
      "evidence is captured to support the exception classification",
      "eligible, exception-free receipts are not blocked by an unrelated exception condition",
      "a likely root-cause category and recommended corrective action can be recorded where evidence supports it"
    ],
    "scope_note": "A negative receiving scenario passes when Oracle correctly raises the expected validation. This scenario does not attempt to certify a specific Oracle application defect. Where an exception appears unexpected or its cause is unclear, it is treated as requiring further investigation and supporting evidence rather than a confirmed conclusion."
  },
  "preconditions": [
    "Oracle Fusion Receiving access is available to the test user.",
    "A representative purchase order, PO line and receiving organization exist that can be placed into a PO exception condition — closed, cancelled, invalid line or fully received line.",
    "Test data required to trigger quantity exception conditions — over receipt, zero quantity, negative quantity or a tolerance violation — is available or can be constructed.",
    "Test data required to trigger item/organization exception conditions — invalid item, invalid receiving organization or a missing lot/serial requirement — is available or can be constructed.",
    "Test data required to trigger dates/configuration exception conditions — invalid date, receiving routing issue, missing location or configuration mismatch — is available or can be constructed.",
    "The test user, or Syntra DataVault, can reproduce or observe exception conditions across all four exception categories."
  ],
  "test_data": [
    {
      "field": "PO Number",
      "example": "${PO_NUMBER}"
    },
    {
      "field": "PO Line",
      "example": "${PO_LINE}"
    },
    {
      "field": "Item",
      "example": "${ITEM}"
    },
    {
      "field": "Receiving Organization",
      "example": "${RECEIVING_ORGANIZATION}"
    },
    {
      "field": "Quantity",
      "example": "${QUANTITY}"
    },
    {
      "field": "Receipt Date",
      "example": "${RECEIPT_DATE}"
    },
    {
      "field": "Exception Category",
      "example": "${EXCEPTION_CATEGORY} — PO / Quantity / Item-Organization / Dates-Configuration"
    },
    {
      "field": "Expected Exception Type",
      "example": "${EXPECTED_EXCEPTION_TYPE}"
    },
    {
      "field": "Tolerance Threshold",
      "example": "${TOLERANCE_THRESHOLD}"
    }
  ],
  "business_steps": [
    {
      "step_number": 1,
      "step_name": "Navigate to Receiving",
      "action": "Navigate to the Oracle Fusion Receiving work area.",
      "test_data": "",
      "expected_result": "The Receiving work area opens successfully.",
      "validation_type": "action"
    },
    {
      "step_number": 2,
      "step_name": "Trigger the Exception Condition",
      "action": "Attempt a receipt that deliberately carries the exception condition under test — a PO, quantity, item/organization or dates/configuration condition.",
      "test_data": "${EXCEPTION_CATEGORY} / ${PO_NUMBER} / ${PO_LINE}",
      "expected_result": "Oracle Fusion processes the receipt against the exception condition rather than silently accepting it.",
      "validation_type": "action",
      "note": "This single business step replaces multiple technical actions such as opening the receipt screen, entering the deliberately invalid value and submitting."
    },
    {
      "step_number": 3,
      "step_name": "Observe the Resulting Exception",
      "action": "Observe the exception, error or validation message returned by Oracle Fusion at the point the condition is triggered.",
      "test_data": "",
      "expected_result": "An exception, error or validation message is displayed or logged for the receipt.",
      "validation_type": "action"
    },
    {
      "step_number": 4,
      "step_name": "Review the Exception Category and Message",
      "action": "Review the exact exception message text and the category it falls under.",
      "test_data": "${EXPECTED_EXCEPTION_TYPE}",
      "expected_result": "The exception message text and category are captured for comparison against the expected classification.",
      "validation_type": "action"
    },
    {
      "step_number": 5,
      "step_name": "Verify the Exception Maps to the Expected Classification",
      "action": "Compare the observed exception against the expected classification for this scenario — PO, Quantity, Item/Organization or Dates/Configuration.",
      "test_data": "",
      "expected_result": "The observed exception matches the expected classification for the triggered condition.",
      "validation_type": "action"
    },
    {
      "step_number": 6,
      "step_name": "Review Evidence Captured for the Exception",
      "action": "Review the evidence captured for the exception, including the PO/receipt reference, screen state and message detail.",
      "test_data": "",
      "expected_result": "Evidence is available to support the exception classification for later review.",
      "validation_type": "action"
    },
    {
      "step_number": 7,
      "step_name": "Determine Likely Root-Cause Category",
      "action": "Assess whether the exception is most consistent with a data, configuration, security, workflow or application-level root cause.",
      "test_data": "",
      "expected_result": "A likely root-cause category is identified based on available evidence. Where the evidence does not clearly point to a specific cause, the exception is flagged for further investigation rather than attributed with certainty.",
      "validation_type": "action",
      "note": "SyntraFlow's failure classification distinguishes data, configuration, security, automation, application, environment and expected-validation causes — for example, a closed or cancelled PO typically points to a data/timing issue, a missing lot/serial requirement typically points to an item setup or configuration issue, and a receiving routing issue typically points to a receiving configuration issue. A possible Oracle application defect is never classified with certainty without supporting evidence."
    },
    {
      "step_number": 8,
      "step_name": "Record Recommended Corrective Action",
      "action": "Record the recommended corrective action for the exception category — for example, select an open PO line, correct the quantity, correct the item/organization combination, or correct the receiving date or routing.",
      "test_data": "",
      "expected_result": "A recommended corrective action is recorded against the exception.",
      "validation_type": "action"
    },
    {
      "step_number": 9,
      "step_name": "Confirm the Exception Does Not Silently Pass",
      "action": "Confirm that the exception condition was not silently accepted or bypassed by Oracle Fusion.",
      "test_data": "",
      "expected_result": "The receipt did not complete as though the exception condition did not exist.",
      "validation_type": "business_assertion"
    },
    {
      "step_number": 10,
      "step_name": "Confirm Receipt Status Correctly Reflects the Exception",
      "action": "Confirm that the resulting receipt or transaction status correctly reflects the unresolved exception.",
      "test_data": "",
      "expected_result": "Receipt status accurately reflects the exception rather than indicating a successful receipt.",
      "validation_type": "business_assertion",
      "note": "This is the main business assertion for the scenario — a correctly detected exception is a passing test, not a failure."
    }
  ],
  "expected_results": [
    "Each exception condition produces the expected Oracle Fusion error or validation message.",
    "The exception message and category match the expected classification for the triggered condition.",
    "Receipt status correctly reflects the unresolved exception rather than silently succeeding.",
    "Evidence is captured to support the exception classification.",
    "Eligible, exception-free receipts are not blocked by an unrelated exception condition.",
    "A likely root-cause category and recommended corrective action are recorded where evidence supports it."
  ],
  "validation_checkpoints": [
    "Each exception category — PO, Quantity, Item/Organization, Dates/Configuration — is correctly identified.",
    "Exception does not silently pass or get bypassed.",
    "Receipt status correctly reflects the exception rather than false completion.",
    "Exception evidence is captured for later review.",
    "Exception maps to the expected classification for the triggered condition.",
    "Eligible receipts are not blocked by unrelated exceptions.",
    "Likely root-cause category is identified where evidence supports it.",
    "Recommended corrective action is recorded against the exception."
  ]
}