shiyuyun/wyndham-ARR
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: sync latest ARR implementation

Browse Source
This commit is contained in:
Wyndham ARR
2026-07-31 15:11:42 +08:00
parent d6f8a747fa
commit bf7939dd1a
185 changed files with 17527 additions and 2260 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
monthly_reports/README.md
View File

@@ -2,17 +2,27 @@
`monthly_reports` is an ordinary deterministic program. It does not call an Agent/Skill and does not read a prior monthly workbook.
Flow:
Automatic flow:
1. Open one `REPEATABLE READ READ ONLY` snapshot of `finance.v_active_daily_facts`, current daily-version pins and current channel metrics.
2. Build the channel worksheets and the 20-column monthly rows from those facts.
3. Reserve a deterministic generation identity and recheck that all daily pins are still current.
4. Generate a typed, formula-free XLSX; reopen and validate it.
5. Recheck current pins before publishing the file to the controlled output/OSS layer.
1. A dedicated worker leases one successful `arr.daily_version_committed` outbox event with `FOR UPDATE SKIP LOCKED`.
2. It looks up that version's retained `ARRIVAL` values in PostgreSQL. The affected month and report watermark come from those facts; the XML filename and wall clock are ignored.
3. It opens a repeatable-read snapshot of current Finance facts and daily-version pins for that month. `as_of_date` is the greatest `ARRIVAL` actually included in the snapshot.
4. It reserves an idempotent publication identity in `reporting.monthly_runs` with immutable daily lineage and channel manifest rows.
5. It generates the XLSX/result JSON, reopens the workbook, validates all values and formulas, and rechecks that the Finance pins are still current.
6. It registers both local artifacts and atomically activates the report. Only then is the outbox event marked `published`; transient failures are retried and exhausted events become `dead`.
Monthly rows and report versions are intentionally not persisted in PostgreSQL. The database remains the source of truth; generated XLSX/result files can be retained as artifacts outside the business fact model.
PostgreSQL stores publication metadata, version identity, lineage and artifact identities—not duplicate monthly business or guest rows. The portal lists `active`/`superseded` runs and downloads only registered artifacts after path, size and SHA-256 checks.
Run:
Run the dedicated worker:
```bash
python3 -m monthly_reports.worker \
--db-config /absolute/path/to/booking-test-db.env \
--node-binary /absolute/path/to/node \
--artifact-tool-module /absolute/path/to/artifact_tool.mjs
```
The CLI generation command remains a controlled recovery/diagnostic entrypoint:
```bash
python3 -m monthly_reports generate \
@@ -24,4 +34,4 @@ python3 -m monthly_reports generate \
The program reads `MONTHLY_REPORT_DATABASE_URL`, falling back to `ARR_DATABASE_URL`. The configured database must be `booking_test`; SuperAgent must never receive the DSN.
`TOTAL PRICE` is copied from the validated daily fact. `Booking Room` enrichment is a separate booking lookup and must not be used to recalculate price, dates or actual room count.
Every XLSX data-row `TOTAL PRICE` cell contains the exact row-relative formula `=R[row]*C[row]*G[row]`, meaning `REAL PRICE × NIGHTS × NO_OF_ROOMS`. The stored Finance `total_price` remains an independent audit expectation. `Booking Room` enrichment must not be used to recalculate price, dates or actual room count.