{
  "test_id": "ORCL.REGRESSION.P2P",
  "scenario_name": "P2P Regression Pack",
  "application": "Oracle Fusion Cloud",
  "product": "Regression",
  "module": "Regression Packs",
  "process": "P2P Regression",
  "business_flow": "Procure-to-Pay Regression",
  "scenario_type": "Regression Pack / Composition",
  "priority": "High",
  "automation_status": "SyntraFlow Ready",
  "library": "Syntra Regression Pack",
  "canonical_url": "https://www.syntraflow.cloud/oracle-erp-testing-tool/test-library/regression-packs/p2p-regression/",
  "objective": {
    "intro": "The objective of the P2P Regression Pack is to give release and QA teams a defined, repeatable set of 20 flow-shaped Oracle Fusion Procure-to-Pay scenarios — spanning Supplier, Requisition, Approval, PO, Receipt, AP Invoice, Validation, Payment and Accounting — that can be run together ahead of a quarterly update, patch or configuration change, without needing to execute the full 45-scenario Procure-to-Pay End-to-End journey every cycle.",
    "confirms": [
      "the 20 referenced REG-P2P scenario IDs are correctly composed from their underlying Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages",
      "quantity and amount correctly carry across the flow — from requisition into PO, PO into receipt, receipt into invoice match, and validated invoice into payment and accounting",
      "three-way match integrity is correctly enforced, with quantity and price mismatches correctly placed on hold rather than silently validated",
      "negative and security validations are correctly enforced across the composed pack rather than only within a single family page",
      "a batch execution of the pack correctly records pass/fail status per scenario, with failures classified into a likely root-cause category",
      "the pack can be scheduled and re-run on a defined cadence, such as ahead of a quarterly Oracle update",
      "unauthorized users are correctly blocked from creating or approving a transaction at any stage of the flow"
    ],
    "scope_note": "This pack does not duplicate the individual field-level scenario coverage already tested on the Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages. It also does not duplicate the detailed, step-by-step 45-scenario coverage documented on the Procure-to-Pay End-to-End journey page — this compact 20-scenario pack references those same scenario IDs and family pages, but is scoped for faster, more frequent regression runs. For full step-by-step detail on any stage of the flow, see the Procure-to-Pay End-to-End journey."
  },
  "preconditions": [
    "The Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages referenced by this pack's 20 scenario IDs are individually functional in the target Oracle Fusion environment.",
    "A valid supplier, item, purchase order and accounting period are available and enabled across Procurement and Accounts Payable.",
    "The test user holds the roles required to execute each referenced scenario, or alternate unauthorized-user personas are available for security testing.",
    "DataVault test data bindings for the referenced scenario IDs are current for the environment under test.",
    "Approval hierarchies, match tolerances, payment methods and security roles are configured according to the target environment — this pack does not assume a single universal configuration applies to every scenario."
  ],
  "test_data": [
    {
      "field": "Supplier",
      "example": "${SUPPLIER}"
    },
    {
      "field": "Requisition",
      "example": "${REQUISITION}"
    },
    {
      "field": "PO Number",
      "example": "${PO_NUMBER}"
    },
    {
      "field": "Item",
      "example": "${ITEM}"
    },
    {
      "field": "Quantity",
      "example": "${QUANTITY}"
    },
    {
      "field": "Receipt",
      "example": "${RECEIPT}"
    },
    {
      "field": "Invoice",
      "example": "${INVOICE}"
    },
    {
      "field": "Amount",
      "example": "${AMOUNT}"
    },
    {
      "field": "Payment",
      "example": "${PAYMENT}"
    },
    {
      "field": "Accounting Period",
      "example": "${ACCOUNTING_PERIOD}"
    }
  ],
  "business_steps": [
    {
      "step_number": 1,
      "step_name": "Confirm Supplier Readiness",
      "action": "Confirm supplier ${SUPPLIER} is active, enabled for procurement and holds valid banking setup, referencing the standard Suppliers family page.",
      "test_data": "${SUPPLIER}",
      "expected_result": "Supplier ${SUPPLIER} is correctly active and available for requisitioning and payment.",
      "validation_type": "action"
    },
    {
      "step_number": 2,
      "step_name": "Create the Requisition",
      "action": "Create requisition ${REQUISITION} for item ${ITEM} and quantity ${QUANTITY}, referencing the standard Requisitions family page and scenario REG-P2P-001.",
      "test_data": "${REQUISITION} / ${ITEM} / ${QUANTITY}",
      "expected_result": "The requisition is correctly created with supplier, line and quantity detail carried forward.",
      "validation_type": "action"
    },
    {
      "step_number": 3,
      "step_name": "Route the Requisition Approval",
      "action": "Route requisition ${REQUISITION} through requisition approval per the configured hierarchy, referencing the standard Requisitions family page and scenario REG-P2P-002.",
      "test_data": "${REQUISITION}",
      "expected_result": "Requisition approval is correctly enforced per the configured hierarchy before PO conversion.",
      "validation_type": "action"
    },
    {
      "step_number": 4,
      "step_name": "Create and Approve the PO",
      "action": "Convert the approved requisition into purchase order ${PO_NUMBER} and route it through PO approval, referencing the standard Purchase Orders family page and scenario REG-P2P-003.",
      "test_data": "${PO_NUMBER} / ${SUPPLIER}",
      "expected_result": "The purchase order is correctly created and approved, carrying requisition, supplier and price detail forward without discrepancy.",
      "validation_type": "action"
    },
    {
      "step_number": 5,
      "step_name": "Receive Against the PO",
      "action": "Record a receipt ${RECEIPT} against purchase order ${PO_NUMBER}, including full, partial and corrected receipt paths, referencing the standard Receiving family page and scenarios REG-P2P-004 through REG-P2P-006.",
      "test_data": "${RECEIPT} / ${PO_NUMBER} / ${QUANTITY}",
      "expected_result": "Received quantity is correctly recorded against the PO, with partial receipts and corrections correctly reflected in open PO quantity.",
      "validation_type": "action"
    },
    {
      "step_number": 6,
      "step_name": "Create the AP Invoice",
      "action": "Create invoice ${INVOICE} matched to purchase order ${PO_NUMBER} or, where supported, to receipt ${RECEIPT}, referencing the standard AP Invoice Processing family page and scenarios REG-P2P-007 and REG-P2P-008.",
      "test_data": "${INVOICE} / ${PO_NUMBER} / ${AMOUNT}",
      "expected_result": "The invoice is correctly created and carries forward matched quantity and amount from the referenced PO or receipt.",
      "validation_type": "action"
    },
    {
      "step_number": 7,
      "step_name": "Validate the Match",
      "action": "Validate invoice ${INVOICE} against its matched PO and receipt, confirming quantity and price mismatches are correctly placed on hold and resolved holds correctly clear for payment, referencing the standard AP Invoice Processing family page and scenarios REG-P2P-009 through REG-P2P-012.",
      "test_data": "${INVOICE} / ${AMOUNT}",
      "expected_result": "Three-way match integrity is correctly enforced — mismatches are correctly flagged rather than silently validated, and resolved holds correctly clear.",
      "validation_type": "business_assertion",
      "note": "This is a primary business assertion for the pack — correctly enforced match integrity, not merely a successful invoice creation, is the expected pass condition."
    },
    {
      "step_number": 8,
      "step_name": "Process the Payment",
      "action": "Process payment ${PAYMENT} for validated invoice ${INVOICE} — full, partial, via Payment Process Request, electronic, held or voided and repaid — referencing the standard AP Payments family page and scenarios REG-P2P-013 through REG-P2P-019.",
      "test_data": "${PAYMENT} / ${AMOUNT} / ${SUPPLIER}",
      "expected_result": "Payment is correctly created against the validated invoice amount, with holds, voids and reissues correctly reflected in supplier balance.",
      "validation_type": "action"
    },
    {
      "step_number": 9,
      "step_name": "Verify Accounting Continuity",
      "action": "Confirm the accounting entries generated across requisition, PO, receipt, invoice and payment remain correctly consistent end-to-end, referencing scenario REG-P2P-020 and, for full step-by-step detail, the Procure-to-Pay End-to-End journey.",
      "test_data": "${AMOUNT} / ${ACCOUNTING_PERIOD}",
      "expected_result": "Accounting entries correctly reconcile from requisition through payment, with no orphaned or mismatched accounting lines.",
      "validation_type": "business_assertion",
      "note": "This is the final business assertion for the pack — correctly reconciled accounting continuity across all nine flow stages is the expected pass condition."
    }
  ],
  "expected_results": [
    "All 20 referenced REG-P2P scenario IDs are correctly included and resolvable against the target environment.",
    "Test data binds correctly to each scenario via DataVault before execution.",
    "Each scenario in the batch run records a pass, fail or exception status.",
    "Quantity and amount continuity remain correctly consistent from requisition through PO, receipt, invoice and payment.",
    "Three-way match mismatches are correctly flagged on hold rather than silently validated, and resolved holds correctly clear.",
    "Any failure is correctly classified into a likely root-cause category rather than assumed to be an Oracle defect.",
    "The pack's aggregate result is available as evidence for a release go/no-go decision."
  ],
  "validation_checkpoints": [
    "all 20 scenario IDs correctly resolved from their referenced family pages",
    "DataVault test data correctly bound to each scenario before execution",
    "batch execution correctly records pass/fail/exception per scenario",
    "quantity and amount continuity correctly maintained across the flow",
    "quantity and price mismatches correctly placed on hold rather than silently validated",
    "negative and security scenarios correctly enforce the expected restriction",
    "failed scenarios correctly classified using the 8-category taxonomy",
    "aggregate pack result correctly available for release sign-off"
  ]
}