Companion to Oracle Hospitality OPERA Report Scheduling and SFTP Delivery to d2o PMI. Use the main guide for system ownership, report parameters, revenue semantics, SFTP setup, the file contract, security controls and acceptance tests. This companion covers incident diagnosis, recovery and support evidence.
About this guide
This article contains information compiled from publicly available Oracle Hospitality documentation, d2o Knowledge Base articles, and other external technical documentation. Information relating to Oracle OPERA functionality has not necessarily been independently verified by d2o and may vary by OPERA version, configuration, hosting model, and report definition. Confirm version-specific or customer-specific configuration before making production changes.
This guide supports implementation, operations, and incident investigation for report-based OPERA integrations with PMI. It covers OPERA 5, OPERA Cloud, and the boundary with Reporting and Analytics (R&A). It is not a customer-specific configuration specification.
Current public OPERA Cloud 26.2 documentation and OPERA 5.6 help were consulted. This does not establish the customer's installed release or prove that 26.2 is the latest available release in every region. No customer environment, raw export, private Oracle support article, or PMI parser configuration was inspected. All procedures below must use the agreed customer integration contract.
TOTAL_REVENUE equals zero
What is and is not established
The reviewed public sources do not establish a universal mapping from the raw export field TOTAL_REVENUE to the displayed Room Revenue, nor a documented Oracle defect that always produces zero in that field. Do not label the customer's symptom a known product bug without a matching Oracle support reference and affected version.
Inspect the exact field in the raw file. Distinguish numeric zero, blank, null, missing field, and a conversion error displayed as zero by the importer. Confirm whether the value is on a detail row, subtotal, or report-total record. Obtain a previously accepted export from the same integration if available.
First isolation test
Run a short date range containing a known paid reservation. Use the same internal report, property, filters, grouping, rate mode, currency, and resolved dates as the scheduled job. Generate a human-readable view and the actual integration format. Compare manual output, scheduled output before delivery where available, received raw file, and PMI result.
| Observation | Investigate next |
| Rendered report and raw export both show zero | Reservation/rate data, selected population, calculation mode, report definition |
| Rendered report has revenue; manual raw export has zero | Export field meaning, output format, grouping, report/template version |
| Manual raw export is correct; scheduled raw export is zero | Saved scheduled parameters, report identity, context, resolved dates |
| Scheduled raw export is correct; received file differs | Wrong file/job/path, overwriting, intermediary processing |
| Received raw file is correct; PMI shows zero | Parser mapping, decimal conversion, property/market mapping, import rejection or stale data |
A zero already present before transfer means that transfer is not the origin of that particular zero. It does not rule out a separate delivery problem.
Controlled revenue test
- Choose an existing future reservation with a known nonzero charge; record its date, rate code, room type, market, package, and block association without guest-identifying details.
- Capture the relevant reservation-level amount using the version-specific revenue comparison described under Revenue and block semantics in the main setup guide.
- Run the agreed production revenue mode for a narrow range; retain report and raw export.
- Make a diagnostic comparison using the alternate rate mode, changing only that setting. Keep test output outside production ingestion.
- Compare which fields change, which remain zero, and whether the difference can be reconciled to package/tax components.
- Repeat with a reservation without a package, then with the relevant block scenario.
- Ask the OPERA owner to investigate classifications or rate/package setup only where the evidence points there. Ask d2o to confirm the intended imported revenue measure.
interpretation: a nonzero result in the alternate mode is evidence about the calculation path, not permission to change the financial definition of the integration. Do not switch permanently to Package Rate simply to eliminate zeros. Do not change accounting classifications or existing reservations merely to make an export populate.
Hypotheses to test, not established defects
| Hypothesis | Evidence that would support it |
| Wrong report instance or template | Different internal name/revision between working and failing run |
| Saved filter excludes paid reservations | Known sample absent from report population |
| Rate/package or classification issue | Reservation-level expected amount inconsistent with the selected measure |
| Unpicked-up block population behaves differently | Failure isolated to that controlled block case |
| Incorrect raw-field mapping | Another raw field reconciles to the visible revenue, with schema confirmation |
| Output layout breaks extraction | Same data exports correctly in a supported integration layout |
| Locale conversion defaults to zero | Raw amount is nonzero; parser diagnostics show conversion failure |
| Wrong or stale file imported | Run time, property, checksum, or import ID does not match the test |
Operational troubleshooting
The following are recommended diagnostic paths, not a list of confirmed Oracle bugs. Error wording varies by implementation.
| Symptom | First checks | Useful evidence / next owner |
| Scheduler unavailable | Enabled control/function, role permissions, product family | Screenshot and role/control record; OPERA administrator |
| Report absent from selection | Internal name, property context, permissions, available report set | Report configuration; OPERA owner |
| Job never runs | Active owner, pause/end date, next run, time zone, maintenance | Execution history; OPERA/hosting |
| Job runs late | Runtime, backlog, overlapping jobs, business-date transition | Start/end times and queue evidence |
| Empty report | Resolved dates, property, filters, known matching reservation | Controlled sample and parameters |
| Revenue all zero | Follow TOTAL_REVENUE equals zero above before changing transport | Report plus raw export |
| Revenue too high | Wrong measure, totals counted twice, duplicated import | Breakdown by date/market and import record |
| Room counts differ | Population/block state, grouping, inclusion rules | Matched sample set |
| Export differs from preview | Format, grouping, template/field mapping | Same-run outputs; Oracle and d2o |
| Host cannot be resolved | DNS from actual source, spelling, environment | Resolver error and origin |
| Connection timeout | Egress/ingress rules, wrong port, routing, proxy | Both-side timestamped logs |
| Connection refused | Correct host/port, listening service, endpoint availability | SFTP operator |
| SSH negotiation fails | Compatible algorithms and deployed client version | Exact negotiation error; Oracle/SFTP owner |
| Host-key mismatch | Trusted fingerprint and planned rotation | Independently confirmed new key |
| Authentication fails | Account, selected auth mode, key registration, passphrase, expiry | Sanitized auth logs |
| Permission denied during upload | Exact failing operation, path, quota, ownership | Server operation log |
| Validate succeeds, delivery fails | Actual report folder, filename, file size, runtime account | Real upload log and job destination |
| Delivery succeeds, file seems absent | Different root/path, immediate pickup/archive, overwrite | Receipt/archive record, exact filename/time |
| File received, no PMI update | Recognition, property mapping, parser rejection, import backlog | d2o import ID and rejection details |
| Intermittent truncated file | Reader starts before upload completes, interrupted upload | Byte counts, timestamps, pickup protocol |
| Yesterday's values recur | Fixed dates, stale output, wrong job/file, older replay | Resolved dates, snapshot time, checksums |
report-error handling: preserve the exact Oracle error code and message, execution ID, start/end time, and parameters. For runtime, database, or template errors, first reproduce with a short range and standard report if available. Do not guess a root cause from a generic ORA-/REP- prefix, edit database tables directly, or repeatedly launch large jobs into an existing backlog. Oracle support needs the full error and installed version to identify a relevant defect or patch.
Timeouts, retries, duplicates, and recovery
Separate timeout stages
Distinguish report generation, DNS/TCP connection, SSH negotiation, authentication, idle transfer, whole-transfer duration, and downstream import wait. Measure the failing stage before extending a timeout. Capture whether the server received nothing, a partial file, or the complete file before the sender reported failure.
No universal OPERA retry count, backoff, timeout value, exactly-once delivery guarantee, or PMI deduplication policy was established from the reviewed sources. Obtain the behavior for this deployment. Do not document invented defaults.
Safe retries
A transient network failure may justify a bounded retry; invalid credentials, unknown host keys, invalid paths, and schema failures require correction first. As a locally agreed policy (not an Oracle default), use increasing delays and a maximum attempt count, then alert the owner. Avoid retries overlapping the next scheduled run.
After an ambiguous upload result, check d2o receipt and import history before resending. Record whether the retry reuses the original file or regenerates the report. A regenerated forecast is a new snapshot and may contain changed bookings.
Duplicate and overwrite control
Establish the authoritative writer for each property/report. Check for duplicate schedules, a parallel legacy File Agent route, and manual uploads into the same production feed.
| Risk | Control to agree with d2o |
| Fixed filename overwritten before pickup | Receipt acknowledgement or archive before replacement |
| Unique filename rejected | Use only an accepted naming pattern |
| Same file replayed | Content hash plus receipt/import history and agreed idempotency |
| New snapshot has same name | Track snapshot/run identity, not filename alone |
| Older snapshot arrives after newer snapshot | Prevent stale replacement according to agreed ordering rules |
| Subtotals imported as detail | Explicit record-type/grain rules |
| Partial file picked up | Agreed completion protocol or verified stable-file handling |
Uploading under a temporary name and renaming after completion can be useful only if both sender and receiver support and agree it. Do not assume OPERA offers this option or that d2o ignores temporary files. A quiet size interval is a heuristic, not a universal atomic-delivery guarantee.
Missing files and backfill
- Identify the missing property, report, expected run, and data interval.
- Check whether generation, upload, receipt, or import failed.
- Preserve any original successfully generated file and failed-run evidence.
- Ask d2o whether replay replaces or appends, and whether a newer snapshot already exists.
- Replay the original if appropriate, or regenerate with clearly recorded current snapshot time.
- Verify import completion and business totals; close only the affected gap.
A new forecast is not historical evidence of yesterday's OTB position. If the original snapshot is lost, mark that limitation explicitly. For historical actuals, use the agreed historical report and interval. Never rename a current forecast to imply it was generated on an earlier date.
Support evidence template
Copy this template into an internal incident record. Do not include credentials or guest names.
Incident / owner: Property in OPERA / property in PMI: Product, release, patch, hosting model: Route: direct SFTP / legacy File Agent / other: Internal report name, display name, template revision: Expected result / actual result: First failure / last known success: Execution ID and timestamps with time zone: Business date / report first and last dates / snapshot time: Schedule owner active? Schedule active? Next execution: Filters, grouping, block statuses, revenue mode, currency: Manual reproduction result: Saved-job force-run result: Raw field name, sample value, detail/subtotal/total record: Source filename, byte count, hash if available: Destination code, hostname, port, remote folder (no secrets): Authentication type and key reference (no private key): Actual source system / egress IP confirmed by operator: Exact sanitized error and stage: d2o receipt timestamp / received bytes / import ID: Parser rejection or mapping evidence: Recent OPERA, network, credential, report, or parser changes: Changes already tested and results: Replay performed? Original file or regenerated snapshot: Next owner / requested action / resolution evidence:
For TOTAL_REVENUE=0, attach the controlled raw export and matching report view, parameter record, expected amount calculation, and an anonymized reservation example. Ask Oracle about report/export behavior and d2o about schema/import behavior using the same sample.
Sources
Sources were consulted on 11 September 2026. Links throughout the guide identify the source supporting each product claim. Recheck version-specific instructions when the deployed release changes. No unpublished Oracle support content is claimed as verified.
| Source | Scope and use |
| d2o manual Reservation Forecast | Requested starting point; manual name/path/date instructions; historical-text inconsistency |
| d2o scheduled Reservation Forecast | Scheduled report baseline |
| d2o export overview | Daily report families and transfer ownership |
| d2o SFTP transfer | Destination creation and report linkage |
| d2o Cloud reports | Cloud workflow context and M&E scope |
| Oracle OPERA 5.6 res_forecast1 | Revenue modes and block behavior |
| Oracle OPERA 5.6 scheduler | Parameters, destinations, dates, time zones, filename tokens |
| Oracle OPERA 5.6 delivery methods | Version-specific SFTP configuration |
| Oracle OPERA 5.5.1 scheduler | Older deployment proxy guidance |
| Oracle Cloud 26.2 scheduler | Scheduling operations, owner inactivity, delivery status, R&A exclusion |
| Oracle Cloud 26.2 SFTP | Destination fields, authentication, host keys, folder validation |
| Oracle Cloud 26.1 User Guide | Dynamic date validation |
| Oracle Cloud 26.1 report configuration | Multiple report instances and preset parameters |
| Oracle Cloud 26.1 generating reports | Output formats and grouped-layout export warning |
| Oracle Cloud 25.4 forecast reports | Forecast report identifiers |
| Oracle R&A scheduled reports | Separate R&A scheduling system |
Suggested maintenance owner: d2o integrations / internal KB owner. Review after major OPERA upgrades or a confirmed integration defect, and incorporate customer-specific findings only with their scope and evidence recorded.
Main setup guide
Return to Oracle Hospitality OPERA Report Scheduling and SFTP Delivery to d2o PMI for configuration and validation.