Property & Project
A customer is the property. A project is one build for it — and each project targets one environment, so a Configuration build and the later Live build stay separate sets of data.
New customer
New project
Property identity
What Oracle needs to recognise the property. The resort code goes in column A of every row of an Accelerator workbook and is what its import matches on — without it the export builds, but nothing will load it.
Active project
Revenue Centres
Every centre that takes revenue, and the serving periods it offers. Each centre takes a 1,000-number block: one 100-number sub-block per serving period, plus all-day, adjustment, service-charge, and tax bands.
Add a revenue centre
Serving periods and POS posting are set per centre below, once it exists.
Centres
What this will generate
A preview, written to nothing. Period sub-blocks are posted by the POS and carry no generates — the interface sends its own tax. The manual and adjustment blocks always carry the full tax chain.
OPERA Controls
Upload the OPERA Controls reference workbook. It parses into yes/no functions. Tick the ones worth asking a customer — those get added to the Intake questionnaire. The rest stay here as your internal scoping checklist. The "Applies to config item" column is what puts the Controls flag on an item in Configuration Items.
Customer checklist
Oracle's own controls workbook has three sheets and no stable key, so an app cannot tell which sheet a customer filled or match a row back to the control it answered. This generates our own single sheet instead — every control, one Yes/No column, and a Control Key column that makes the round trip exact. Functions today; parameters are a later version, which is why the sheet already carries a Type column.
Internal scoping checklist
Tick the controls worth putting on the customer's basic intake sheet, and map each one to the config item it calls for.
Intake
The same questions two ways: download the sheet and send it to the customer, or fill it in here yourself. Both land in the same place. Questions marked Controls came from the workbook you uploaded; the rest are always asked.
Excel round trip
Regenerate the template after changing what's curated in OPERA Controls: npm run generate-template
Fill in directly
Typing is saved on its own a second after you stop — you can close this and come back. The button below is only for forcing a save now.
Generation builds Room Types, Rate Codes, Cancellation Reasons and Back-Office rows from these answers, then drops you in Configuration Items to review them.
Configuration Items
Every item in the real Accelerator Workbook, grouped the way OPERA Cloud Administration groups them. Required is mandatory whatever the controls say; Controls means this customer's own answers call for it. Per item: tick Oracle's recommended codes to use them as-is, and add property-specific rows underneath.
Select an item on the left.
Bulk Edit
Describe a change in plain English and it's turned into an add, update or remove against one config item. Nothing is written until you confirm the preview.
Transaction Codes
Built from the revenue centres and the serving periods each one offers. Each centre takes a 1,000-number block with stable sub-blocks for periods, manual postings, adjustments, service charge, and tax.
How the codes are numbered
Our scheme, not a chain's. Every code says what it is by where its digits sit, so a consultant can explain any number on the sheet without looking it up.
Transaction configuration plan
Create in this order: Groups → Subgroups → Transaction Codes. Keep all three selected for a complete outlet configuration.
Writes complete draft rows into the selected configuration items. Re-running replaces only rows generated by this workflow—anything entered manually survives. Each centre's code block is pinned on first generation, so adding a centre later never renumbers codes already loaded into OPERA.
Generates — the tax chain
Two sources, and only two: the Oman standard, which is fixed by the tax authority and which no property may deviate from without its auditors and written acceptance; or rules the property gives us in the Intake, for anywhere that is not Oman. The generates shipped inside chain reference workbooks are deliberately not used — they were built for another jurisdiction. Use Configuration Items → Transaction Codes → Generate taxes? to exclude POS/interface codes that already arrive with tax.
Column Rules
What control each configuration item column gets, and where that came from. Four sources, and they are not equally trustworthy: admin is a decision someone made here, authored is a reviewed correction in code, oracle is the workbook's own data validation, and derived means nothing knew anything and the label was guessed from. Derived is where the work is.
Recommended Codes
The library every property picks from. Everything added here is something no consultant types again — the point is to keep growing it so property-specific entry shrinks and a build becomes mostly transaction codes with the taxes generated.
Export
Every configuration item that has data, as a grid in the exact shape the ARK OPERA Configurator accepts — headers as column labels, rows aligned to them by position. Download it as Excel, or push it straight into a Configurator environment.
What will be exported
Accelerator workbook is Oracle's own format — the four-row header block, the resort code in column A, and a List of Properties sheet. Plain grid is headers on row 1 and data from row 2, which is what the ARK OPERA Configurator's import expects. Same rows, two shapes, because the two consumers want different things.
Push to ARK OPERA Configurator
Sends one PUT /api/config-items/<environment>/<item> per item, in order, so a failure names exactly which item stopped. The Configurator upserts one row per environment and item, so pushing the same project twice overwrites rather than duplicates.
The Configurator's endpoint is behind its own login. Studio signs in for this one push using the details above — they are sent to the Configurator, used to obtain a session for the push, and are not saved anywhere: not in the database, not in a log, not in this browser.