{
  "test_id": "ORCL.HCM.E2E.ABS2PAY",
  "scenario_name": "Absence-to-Pay",
  "application": "Oracle Fusion Cloud",
  "product": "HCM",
  "module": "End-to-End HCM",
  "process": "Absence-to-Pay",
  "business_flow": "Hire-to-Retire",
  "scenario_type": "End-to-End / Cross-Process",
  "priority": "High",
  "automation_status": "SyntraFlow Ready",
  "library": "Syntra Standard Journey",
  "canonical_url": "https://www.syntraflow.cloud/oracle-erp-testing-tool/test-library/hcm/end-to-end/absence-to-pay/",
  "objective": {
    "intro": "The objective of this test is to validate the complete Oracle Fusion Absence-to-Pay journey — worker, absence entry, eligibility and balance check, approval, balance update, payroll impact and payroll calculation, and payment — with emphasis on approved absence correctly reducing the leave balance and correctly reflecting, paid or unpaid, in the payroll calculation, not on re-testing each stage's own atomic, field-level validation. This page is an orchestration and journey test: it does not duplicate the scenario coverage already tested individually on the linked Absence Entry, Absence Validation, Absence Balance, Absence Accrual, Absence Approval, Absence Withdrawal, Payroll Calculation, Payroll Processing, Retro Pay and Payment Processing pages. Instead, it links to those live pages and adds scenarios that specifically test the hand-offs, balance continuity and pay continuity between them.",
    "confirms": [
      "approved absence correctly reduces the leave balance for the worker",
      "only approved absence — not pending, rejected or withdrawn absence — correctly impacts the balance and payroll",
      "paid absence types correctly reflect in the payroll calculation, and unpaid absence types correctly reduce pay where configured",
      "an absence correction made after payroll has calculated correctly triggers a retro calculation",
      "an absence removed after approval correctly restores the balance and triggers payroll recalculation",
      "Oracle correctly enforces validation when data errors, configuration errors, security restrictions or integration failures are introduced at any stage of the journey (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, INTEGRATION_ERROR)"
    ],
    "scope_note": "This scenario orchestrates and links to the individually tested Absence Management and Payroll family pages listed on this page; it does not re-test each stage's own field-level validation, which remains covered on those pages. It covers the standard Absence-to-Pay journey in Oracle Fusion Cloud HCM TEST/UAT environments and does not cover absence plans or accrual rules in isolation, which are covered by the separate HCM Absence Management scenarios outside this journey."
  },
  "preconditions": [
    "A worker ${WORKER} is active and eligible for absence entry in the target Oracle Fusion environment.",
    "Absence Management is configured with the applicable absence plans, accrual rules and approval routing for ${WORKER}'s absence type ${ABSENCE_TYPE}.",
    "The test user or users hold appropriate access to progress a transaction through absence entry, approval, balance update, payroll and payment stages.",
    "Payroll ${PAYROLL} and pay period ${PAY_PERIOD} are defined and open in the target environment, with the absence-to-payroll element mapping configured where applicable.",
    "This scenario assumes each linked family page's own preconditions are separately satisfied — it does not re-verify field-level setup already covered on those pages."
  ],
  "test_data": [
    {
      "field": "Worker",
      "example": "${WORKER}"
    },
    {
      "field": "Absence",
      "example": "${ABSENCE}"
    },
    {
      "field": "Absence Type",
      "example": "${ABSENCE_TYPE}"
    },
    {
      "field": "Absence Days",
      "example": "${ABSENCE_DAYS}"
    },
    {
      "field": "Balance",
      "example": "${BALANCE}"
    },
    {
      "field": "Approver",
      "example": "${MANAGER}"
    },
    {
      "field": "Pay Period",
      "example": "${PAY_PERIOD}"
    }
  ],
  "business_steps": [
    {
      "step_number": 1,
      "step_name": "Enter the Absence Request",
      "action": "Enter absence request ${ABSENCE} of type ${ABSENCE_TYPE} for ${ABSENCE_DAYS} days for ${WORKER}, using the linked Absence Entry scenario.",
      "test_data": "${ABSENCE} / ${WORKER}",
      "expected_result": "The absence request is created with the correct absence type and duration.",
      "validation_type": "action",
      "note": "This step orchestrates the Absence Entry family page rather than repeating its individual field-level test coverage."
    },
    {
      "step_number": 2,
      "step_name": "Verify Eligibility and Balance",
      "action": "Validate absence ${ABSENCE} for ${WORKER} against eligibility rules and the current balance ${BALANCE}, using the linked Absence Validation, Absence Balance and Absence Accrual scenarios.",
      "test_data": "${BALANCE}",
      "expected_result": "Eligible absence with sufficient balance passes validation; ineligible or insufficient-balance absence is correctly flagged.",
      "validation_type": "action"
    },
    {
      "step_number": 3,
      "step_name": "Submit for Approval",
      "action": "Submit absence ${ABSENCE} to manager ${MANAGER} for approval, using the linked Absence Approval scenario, and correct or withdraw via the linked Absence Withdrawal scenario where required.",
      "test_data": "${MANAGER}",
      "expected_result": "The absence is correctly approved by an authorized approver, or rejected/withdrawn and correctly excluded from balance update.",
      "validation_type": "action"
    },
    {
      "step_number": 4,
      "step_name": "Verify Balance Update After Approval",
      "action": "Confirm the leave balance ${BALANCE} for ${WORKER} is correctly reduced by the approved absence duration ${ABSENCE_DAYS} following approval of ${ABSENCE}.",
      "test_data": "${ABSENCE_DAYS}",
      "expected_result": "The balance is correctly reduced by the approved absence duration; unapproved absence does not reduce the balance.",
      "validation_type": "action"
    },
    {
      "step_number": 5,
      "step_name": "Verify the Payroll Impact Reflects the Absence Type",
      "action": "Confirm the approved absence ${ABSENCE} for ${WORKER} correctly maps to the payroll element for absence type ${ABSENCE_TYPE}, correctly reflecting as paid or unpaid ahead of the payroll calculation.",
      "test_data": "${ABSENCE_TYPE}",
      "expected_result": "The absence-to-payroll element mapping correctly reflects the paid or unpaid configuration of ${ABSENCE_TYPE}.",
      "validation_type": "action"
    },
    {
      "step_number": 6,
      "step_name": "Run the Payroll Calculation",
      "action": "Run payroll calculation ${PAYROLL} for pay period ${PAY_PERIOD}, using the linked Payroll Calculation and Payroll Processing scenarios, and the linked Retro Pay scenario where a prior absence correction applies, confirming the absence correctly reflects in the result.",
      "test_data": "${PAY_PERIOD}",
      "expected_result": "The payroll calculation correctly reflects the approved absence as paid or unpaid according to ${ABSENCE_TYPE}.",
      "validation_type": "action"
    },
    {
      "step_number": 7,
      "step_name": "Verify Payment Reflects the Absence Correctly",
      "action": "Trace the completed transaction from absence entry through eligibility/balance, approval, balance update, payroll impact, payroll calculation and payment to confirm the payment amount correctly reflects the absence.",
      "test_data": "",
      "expected_result": "The audit trail correctly links every stage, and the payment amount correctly reflects the paid or unpaid absence.",
      "validation_type": "business_assertion",
      "note": "This is the primary business assertion for the scenario — a fully linked, correctly balanced and correctly paid audit trail across every stage is the expected pass condition, not merely a successful payment."
    }
  ],
  "expected_results": [
    "Absence entries are correctly validated against eligibility and balance before approval.",
    "Only approved absence correctly reduces the leave balance.",
    "Paid absence types correctly reflect in the payroll calculation, and unpaid absence types correctly reduce pay where configured.",
    "Approved absence duration correctly carries into the payroll impact and payroll calculation.",
    "An absence correction made after payroll has calculated correctly triggers a retro calculation.",
    "Unauthorized actions at any stage of the journey are correctly blocked."
  ],
  "validation_checkpoints": [
    "Approved absence correctly reduces the leave balance.",
    "Only approved absence correctly impacts payroll.",
    "Paid vs unpaid absence correctly determines payroll impact.",
    "Absence correction after payroll correctly triggers retro calculation.",
    "Absence removal correctly restores balance and triggers payroll recalculation.",
    "Integration failures correctly flagged rather than silently dropping the absence impact."
  ]
}