For zero-revenue incidents, failed imports, missing files or recovery, use the linked OPERA troubleshooting and recovery guide. This main article covers report configuration, scheduling, SFTP setup and import acceptance.
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.
System boundaries and ownership
Treat these as independently verifiable stages:
Reservation / rate / block data -> report selection and calculations -> rendered report and machine-readable export -> scheduled execution -> SFTP authentication and file upload -> d2o receipt and file recognition -> parsing, mapping, and validation -> PMI data visible for the correct property and dates
Identify the first stage where the result differs from the expected result. A successful upload does not prove a successful import; a successful report execution does not prove delivery. A file containing zero values is a different incident from a missing file.
| Area | Suggested owner | Evidence to request |
| Reservations, rates, packages, blocks | Hotel OPERA administrator / revenue team | Controlled reservation example and expected amounts |
| Report definition and scheduling | OPERA administrator / Oracle support | Internal report name, version, parameters, execution record |
| Hosting and outbound network | Hosting provider / Oracle / network team | Actual source host, egress IP, connection logs |
| SFTP account and destination | d2o or designated SFTP operator | Authentication result, path, upload receipt |
| File recognition and PMI import | d2o integration team | Import ID, parser result, mapping and rejection details |
Product boundaries
OPERA 5 has Reports Scheduler functionality and SFTP destinations. OPERA Cloud has its own scheduled-report workflow. Cloud 26.2 explicitly excludes R&A reports from that scheduler; R&A documents a separate Agents-based scheduling workflow. Do not apply the R&A SFTP setup screen to a standard OPERA Cloud report. Oracle OPERA 5 scheduler, Cloud scheduler, R&A scheduling.
Record whether the existing route is direct OPERA-to-SFTP or a local export collected by the legacy PMI File Agent. The Agent is being phased out and is not recommended for new integrations; agree an API, SFTP or email transfer with d2o. See transfer options. A local outbox is relevant only to an existing Agent route; it is not an SFTP destination path.
Report inventory and implementation prerequisites
d2o: the export overview calls for daily data and identifies the following report purposes. d2o supplies transfer credentials. d2o export overview.
| Report family | Integration purpose |
| Reservation Statistics 1 | Historical room nights and guest nights |
| Trial Balance | Historical revenue |
| Reservation Forecast | On-the-books room revenue, room nights, guest nights |
| Reservation History & Forecast | Arrivals and departures |
| M&E revenue forecast | On-the-books meeting and event revenue |
implementation record:
| Item | Required decision or value |
| Environment | OPERA 5 / Cloud / R&A, exact release, patch, hosting, test/production |
| Property identity | OPERA property code and corresponding PMI property |
| Report identity | Display name, internal name, standard/custom, template revision |
| Revenue definition | Room-only or package-inclusive; tax treatment; currency |
| Selection | Room classes/types, market codes, reservation types, block statuses |
| Dates | Base date, offsets, inclusivity, historical versus future scope |
| Schedule | Time zone, frequency, start/end dates, owner, expected completion deadline |
| Transport | Host, port, account, authentication, host key, remote folder |
| File contract | Name, actual format, encoding, fields, granularity, totals, empty-data behavior |
| Recovery | Duplicate handling, snapshot replacement, replay authority, retention |
| Acceptance | Named hotel and d2o owners; successful delivery and import evidence |
Do not fill unknowns with values copied from another hotel. In particular, no universal d2o SFTP hostname, password, directory, or parser schema is established by this guide.
Reservation Forecast baseline
d2o configuration
d2o Scheduler guide: choose res_forecast1; select all room classes, room types, market codes, and reservation types; enable Block under Reservation Types and Market Code under Options. The guide specifies an end date of today +364 days and suggests running a few minutes after the preceding report. d2o scheduled Reservation Forecast.
d2o manual guide: select res_forecast1, start today and end 12 months ahead, enable Block and Market Code, select File, and save resfct.txt to the PMI Agent Outbox. These filename and folder instructions belong to that manual workflow; confirm the direct SFTP contract separately. d2o manual Reservation Forecast.
Preserve the difference between an internal report identifier (res_forecast1), a KB label (res_forecast), and an output filename (resfct.txt). They are not interchangeable identifiers.
Revenue and block semantics
OPERA 5.6: Net Room Rate restricts Room Revenue to transactions classified as Room Revenue; compare a reservation/date against Reservation → Options → Rate Info → Room Revenue. Package Rate includes room revenue, package revenue, and taxes; compare with Rate Info → Total. Package amounts stored on a reservation can differ from current package configuration. The Block selection includes picked-up reservations and unpicked-up block rooms, with a block-status selector. Oracle's introductory wording also qualifies block calculations in terms of actual reservations; do not assume identical revenue treatment for picked-up and unpicked-up rooms. Oracle res_forecast1.
Validate one individual reservation, one picked-up block reservation, and one unpicked-up block allocation separately. Record count and revenue results; do not infer them from the checkbox label alone.
The cited calculation documentation is OPERA 5.6. Confirm equivalent field definitions and navigation for Cloud and custom report templates. Cloud documentation lists both res_forecast1 and res_forecast2; the existence of both does not make them interchangeable for PMI. Oracle Cloud forecast reports.
Market Code and block checks
Distinguish selecting all market codes in a filter from grouping output by Market Code. Compare the actual saved code list and grouping, not just the visible report title. Determine whether newly created codes are automatically covered or whether a previously saved explicit list needs maintenance.
Validate unmapped or blank codes with d2o; do not silently discard their rows. Compare subtotals by market and date before comparing the grand total. For blocks, record which statuses are included, whether each consumes inventory, pickup state, and whether a usable rate is present. Do not copy M&E block-status instructions into Reservation Forecast: d2o's Cloud page places ACT/DEF/TEN under the Rep_daily_forecast M&E section. d2o Cloud reports.
Manual versus scheduled parameters
OPERA 5.6: the scheduler exposes report Parameters, System Parameters, and date-parameter editing. System Parameters include destination/format information. Cloud: report instances can have different preset defaults even when they share an internal report. OPERA 5 scheduler, Cloud report configuration.
Treat report defaults, a manual run's parameters, and a saved schedule as three configurations until comparison proves equivalence. Do not assume editing a report default updates an existing schedule, or that a successful manual preview tests that schedule.
| Compare explicitly | Record |
| Report | Internal name, display name, custom/standard, revision |
| Scope | Property/hub context and user role |
| Date parameters | Formula and actual dates produced at execution |
| Population | Room filters, market filters, reservation types, deduct settings, block statuses |
| Calculation | Rate mode, currency, revenue options |
| Layout | Grouping, sorting, detail/summary structure |
| Output | Actual format, filename, destination, folder |
Use the saved job's force-run action for the scheduled test, then inspect its execution result. A separate manual report run is a control sample. Keep tests close in time because bookings can change between runs. Save screenshots or parameter exports before and after an approved change; change one factor at a time.
Scheduling and date handling
Product-specific operation
Cloud 26.2: use Reports → Manage Reports → Manage Scheduled Reports. The workflow supports scheduling, editing, pausing, force-running, viewing destinations, and executed reports. Detailed Status includes delivery information. Reports are not generated when the scheduling user becomes inactive in Identity Management. Cloud scheduled reports.
Cloud 26.1: date modifiers can use day/month offsets, and Validate Date evaluates the resulting date against a chosen start date. Oracle Cloud 26.1 User Guide.
OPERA 5.6: scheduled times use property/CRO time-zone rules rather than the user's workstation time; filename placeholders include business date and system date/time. OPERA 5 scheduler.
Configure a durable, accountable scheduling owner consistent with the hotel's identity policy. Include owner status in handover and leaver checks. Do not rely on a personal account whose deactivation can interrupt delivery.
Date boundaries
Document these as separate concepts:
- Execution timestamp: when the report runs, with time zone.
- Business date: the hotel's operational date, potentially different from the calendar date around night audit.
- Stay/report dates: the dates represented inside the file.
- Snapshot timestamp: when the OTB position was observed.
- Receipt/import timestamps: when downstream stages completed.
The two d2o instructions under Reservation Forecast baseline use different horizon descriptions. Today through today +364 contains 365 calendar dates if both endpoints are inclusive. “12 months ahead” is not necessarily the same boundary. Verify the requested first/last date and endpoint inclusion with d2o; test actual output rather than relying on a label.
Test tomorrow's simulated run, month end, year end, leap day where relevant, and a daylight-saving transition. A daily schedule with literal fixed report dates can repeatedly send the same period. Do not assume that changing a filename's date changes the report's data selection.
Frequency and dependencies
Align actuals with the agreed night-audit completion point and OTB with the desired snapshot time. Separate heavy jobs based on measured runtime and allow headroom. Scheduling jobs a few minutes apart is not proof that the first must finish before the next starts. Define a completion deadline for receipt and a later deadline for successful PMI import. Check pause state, expired end date, next execution, queue/backlog, and maintenance windows when a run is missing.
Historical data warning
The manual d2o page says Reservation Forecast cannot run in the past, but also contains a historical-data paragraph suggesting otherwise. This is a source inconsistency, not a validated backfill method. Use the appropriate historical reports and obtain d2o confirmation for historical onboarding. A newly generated forecast cannot by itself reconstruct a past OTB snapshot. d2o manual Reservation Forecast.
SFTP setup
OPERA 5 workflow
d2o: under Property → Delivery Method → General, create an SFTP destination, configure the details supplied by d2o, validate, and confirm test receipt. Add that destination to each report's Distribution List using New → SFTP. Run the report and confirm receipt. Creating a destination alone does not link every report to it. d2o SFTP setup.
OPERA 5 Delivery Method configuration includes SFTP authentication/key handling, but fields and supported formats must be checked for the installed version. Follow the actual UI and its matching help. OPERA 5.6 Delivery Method Maintenance.
OPERA Cloud workflow
Cloud 26.2: SFTP is configured under Toolbox → System Setup → SFTP Configuration, globally or per property. Add the hostname to the Outbound Domain Allowlist first. Configure host, port (default 22), username, authentication, server host key, and folders. Authentication choices include Password, Key, and Key with Passphrase. Validate each folder and revalidate after changes; refresh to see status. Oracle Cloud SFTP destinations.
Ensure the report destination references the intended SFTP code and folder. Confirm that a global destination does not accidentally deliver another property's data into the same import route. Validate actual report delivery after connection validation.
Authentication and host identity
operational distinction:
| Item | Purpose | Handling |
| Username/password | Authenticate the client account | Store in approved secret management; never in the KB |
| Client private key | Authenticate OPERA as the SFTP user | Keep private; load only through the approved configuration workflow |
| Client public key | Authorize that client on the SFTP server | Provide to the SFTP operator for the correct account |
| Private-key passphrase | Protect the private key at rest | Configure only if supported by the chosen authentication mode |
| Server host key | Identify the destination server | Verify against an independently supplied trusted value |
| Host-key fingerprint | Compact identifier for verification | Do not assume a field requesting a full key accepts a fingerprint |
A client key and a server host key are different objects. Successful username/password entry does not resolve a host-key mismatch. Obtain d2o's trusted host-key information through an authenticated channel. A key observed from the network is only a candidate until verified. When a host key changes, investigate a planned rotation or endpoint change before updating trust.
Exact key encodings, key types, signature algorithms, ciphers, and key-exchange support require compatibility verification. Oracle's SFTP page lists SSH options but should not be treated as an exhaustive negotiated algorithm matrix for every patch. Do not globally enable obsolete algorithms or disable host verification to make an old client connect; request a supported compatibility solution.
Connectivity and permissions
test order:
- Confirm hostname, port, account, folder, and environment from the connection record.
- Identify the actual origin of the upload: hosted OPERA, local application server, or File Agent. A successful laptop connection does not test that origin.
- Verify DNS resolution and outbound network access from that origin. Check destination-side source-IP restrictions separately.
- Verify SSH negotiation and trusted server identity.
- Verify account authentication and account/key validity.
- Verify path resolution inside the account's visible root. A chroot-relative path can differ from the server's filesystem path.
- Test creation of a uniquely named non-sensitive file in an agreed test location. Confirm byte count and server-side receipt.
- Test only the additional operations the workflow requires: list, rename, overwrite, or delete. Do not grant broad access speculatively.
- Deliver an actual report and verify PMI import.
An upload-only account may legitimately disallow listing. Conversely, a validation routine may require operations that the production upload itself does not. Obtain logs rather than inferring the failing operation from a generic “permission denied.” Check quota, free space, path traversal rights, filename case, and existing-file ownership.
older OPERA 5 guidance: proxy configuration and SFTP bypass settings can affect delivery. Treat this as deployment-dependent and involve the network owner before altering shared proxy settings. Oracle OPERA 5.5.1 scheduler.
Optional administrator diagnostics
Run these only from an approved diagnostic host, using the actual agreed endpoint. The names below are placeholders, not d2o connection details. These tests do not replace testing the OPERA runtime's own connection.
# Windows: name resolution and TCP reachability only Resolve-DnsName sftp.example.invalid Test-NetConnection -ComputerName sftp.example.invalid -Port 22 # Preserve a file identity for comparison; replace the local sample path Get-FileHash -LiteralPath 'C:\IntegrationTest\resfct.txt' -Algorithm SHA256
With an approved OpenSSH client and a previously verified known-hosts entry:
sftp -v -oStrictHostKeyChecking=yes -P 22 integration_user@sftp.example.invalid
Use verbose output to distinguish negotiation, authentication, and path errors; sanitize it before sharing. Do not put passwords in commands. A TCP success proves only port reachability. An interactive client may support algorithms or credentials that the deployed OPERA client does not.
OpenSSH tooling: ssh-keyscan gathers server host keys but does not authenticate them. If used to obtain a candidate key, compare it through an independent trusted channel before installation. The sftp client supports verbose diagnostics and SSH options; its settings are not OPERA scheduler settings. OpenBSD ssh-keyscan manual, OpenBSD sftp manual.
File contract and import validation
Agree the contract before production. A .txt extension does not establish delimiter, schema, encoding, or whether the content is an integration-safe layout.
| Contract element | Confirm with d2o |
| Recognition | Exact filename or accepted pattern; case sensitivity; property routing |
| Format | XML, delimited text, fixed-width text, or another explicitly accepted format |
| Encoding | Character encoding, BOM handling, line endings |
| Numeric/date syntax | Decimal and thousands separators, negative values, date order, time zone |
| Structure | Headers, field names/order, quoting, escaping, repeated page headings |
| Row meaning | Detail versus subtotal/total; date and market grain; uniqueness key |
| Measures | Revenue semantics, currency, room nights, guest nights, rounding |
| Missing values | Difference between zero, blank, null, absent row, and empty file |
| Load behavior | Snapshot replacement versus append/delta; deletion and cancellation handling |
| Delivery | Compression, temporary names, completion markers, overwrite behavior |
Cloud 26.1: available formats depend on the report. Oracle warns that Delimited/Delimited Data for complex grouped layouts can duplicate rows or omit rows. Do not select a format solely because it opens easily in Excel. Oracle generating reports.
raw-file checks: retain an unchanged original; record byte count and SHA-256 if tooling is available; inspect it without resaving through spreadsheet software. Verify first/last data date, property, field names, row count, and monetary totals. Exclude subtotals from detail sums. Distinguish “no row for a date” from “zero for that date.” Ask d2o whether zero-activity dates must be emitted.
Compare source and destination hashes only when both are the same untransformed file. Different hashes after an intentional conversion require a semantic comparison; they do not automatically prove corruption. Confirm that the import inspected is the one associated with this receipt, not a previous successful file.
Security and change management
All items in this section are recommended operating controls.
- Use a dedicated integration identity with access limited to the intended property/folder and required operations.
- Store passwords, private keys, and passphrases in approved secret storage; include only secret references in tickets and documentation.
- Verify host identity independently. Do not bypass host-key verification to clear an incident.
- Keep production and test destinations distinct and prevent diagnostic files from entering production imports unintentionally.
- Minimize exported personal data. Use anonymized samples and restricted diagnostic storage; define retention and deletion with the data owner.
- Distinguish transport protection from file protection after receipt. Do not describe an ordinary SFTP upload as providing persistent encryption of the stored report.
- Review logs and screenshots for secrets and guest data before sharing. Use approved support channels.
- Plan credential/key rotations with both ends, an overlap window where supported, validation, actual delivery, and removal of superseded access.
- Record server host-key rotation separately from client credential rotation.
- Patch and test compatibility through supported release paths. Avoid changing shared security settings for one integration without assessing other users.
Before a change, save the current non-secret configuration and a known-good sample. Document the intended effect, rollback, responsible owner, and acceptance evidence. Re-test after an OPERA upgrade, template change, market-code change, destination migration, credential rotation, or parser update.
Acceptance tests and monitoring
Go-live checklist
- [ ] Product/version, internal report name, and property are recorded.
- [ ] Revenue definition and field mapping are approved by d2o and the hotel.
- [ ] Dates resolve correctly today and for a future scheduled run.
- [ ] Block and Market Code behavior is reconciled using controlled examples.
- [ ] Manual and saved-job outputs reconcile under equivalent conditions.
- [ ] Raw file matches the accepted contract, including zero/empty handling.
- [ ] Destination and host key are verified; actual upload succeeds.
- [ ] d2o confirms exact file receipt and successful import for the correct property.
- [ ] Revenue, room nights, guest nights, and required horizon reconcile.
- [ ] Duplicate/replay behavior is established without double counting.
- [ ] A normal unattended scheduled run succeeds; force-run success alone is insufficient.
- [ ] Monitoring, escalation owners, credential lifecycle, and recovery are documented.
Daily monitoring
Track expected versus completed execution, receipt, and import separately. Log property, report, run identity, schedule time zone, business date, covered dates, bytes, row count, selected control totals, delivery result, and import ID. Alert on missing deadlines, repeated failures, unusually small/empty files, an unexpectedly shortened horizon, unmapped markets, and revenue becoming zero while room nights remain material.
Thresholds should reflect the hotel's operating pattern; seasonal closure or a genuinely empty future date can be valid. Avoid alerts based solely on a fixed expected row count when grouping or zero-row suppression can change it. Distinguish “no new data” from “an attempted import failed.”
Reconciliation examples
Select a small date/market slice and reconcile it through all stages. Compare amounts at the same grain and currency, excluding report totals. If rounding is involved, agree a tolerance based on the calculation; do not invent a universal tolerance. Investigate cancellation or market reassignment behavior by comparing successive snapshots in an approved test, verifying that obsolete values do not remain in PMI.
Documentation gaps and corrections
| Item | Status | Required follow-up |
| TOTAL_REVENUE mapping | Not established for customer's export | Obtain raw schema/sample and d2o mapping confirmation |
| All-zero revenue as a known Oracle bug | Not established | Match exact version and reproduction to an Oracle SR/defect |
| Historical use of Reservation Forecast | Contradictory d2o manual text | Ask KB owner to correct historical paragraph |
| 12 months versus +364 days | Different source wording | Agree exact inclusive horizon |
| Correct Net/Package choice for PMI | Customer contract required | Confirm intended revenue semantics before changing |
| Cloud versus OPERA 5 report fields | Depends on the deployed version | Validate deployed report, not only its name |
| SFTP credentials/path and naming | Customer-specific | Obtain d2o connection sheet and accepted sample |
| Retry/timeout/overwrite/idempotency | Not publicly established here | Record tested behavior and operational policy |
| SSH compatibility | Release/patch-dependent | Confirm actual negotiated algorithms and supported key format |
Oracle's reviewed Cloud SFTP help uses OAuth-related wording under SSH key authentication, while its fields request a private key and server host key. Treat that wording as a documentation ambiguity; do not add an OAuth token configuration to an SSH workflow based on it. The older OPERA 5 help also describes private-key use as encrypting the export file; do not infer persistent file encryption from that wording. Cloud SFTP help, older OPERA delivery help.
Public setup articles can explain configuration but cannot establish the root cause of a specific customer's incident. A support finding should record reproducible evidence, affected versions, and any confirmed fix separately from this general guide.
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.
Related troubleshooting
Troubleshooting Oracle OPERA report imports and SFTP delivery covers TOTAL_REVENUE equals zero, operational troubleshooting, timeouts, retries, duplicates, missing files and the support evidence template.