shiyuyun/wyndham-ARR
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bf7939dd1ad8b3914e1075db0f6618b1812012ba
wyndham-ARR/.project-docs/50-evidence/topics/2026-07-30-company-report-path-and-month-end-readiness.md
Wyndham ARR bf7939dd1a feat: sync latest ARR implementation
2026-07-31 15:11:42 +08:00

7.6 KiB
Raw Blame History

Evidence Topic: Company-report path and July month-end readiness

Metadata

  • Date: 2026-07-30
  • Status: Processor and Booking runtime ready; released 5/5 live job pending
  • Scope: ARR2 local Web on port 8766, accepted company_reports processor, controlled booking_test snapshot
  • Confidence: Fact
  • Source: code/input inspection, live health/job metadata, repeatable-read aggregate queries, pure in-memory report build, real XLSX tests
  • Last verified: 2026-07-31 11:34 +08:00
  • Stale trigger: port-8766 restart, first Booking draft activation, Finance current-version repair, Booking source/parse changes, or a new July upload

Question

What path and rules does the current “公司渠道明细” program use, and will the July month-end run publish all five workbooks from the current database projection?

Evidence

  • The active Web process includes --enable-company-reports; loopback health reported company_reports_ready=true at 2026-07-30 15:35 Asia/Bangkok.
  • The Web coordinator accepts one month and one cumulative cutoff period, enforces the Bangkok release boundary, and invokes the deterministic processor for the fixed five-company set. It does not read XML or call an Agent.
  • The source query reads finance.v_active_daily_facts by DEPARTURE from month start through the cutoff in a repeatable-read, read-only transaction. Booking enrichment comes only from current accepted room items, joined by normalized complete Group Code.
  • Two persisted Web jobs for 2026-07 cutoff 10 and cutoff 20 both completed 5/5 successfully with zero rows for every company. The current supported-company facts all have C/O in the 21-to-month-end period, so those are valid empty workbooks rather than dropped rows.
  • A read-only July 31 aggregate found 417 supported-company facts: 121 matched, 11 unmatched, and 285 missing_group_code. Missing Group Code counts are LianTai 120, QBD 128, DY-AI-Easy-KB 1, FengRun 33 and HanaTour 3.
  • Under the prior strict rule, a pure in-memory preview blocked all five companies because every missing Group Code was an error. The user then explicitly chose the deterministic fallback: keep each such Finance fact as its own output row with blank RES_COMMENT and blank Booking Room, without warning or duplicate highlighting. At that intermediate step, present-but-unmatched Group Codes still remained strict source-completeness errors.
  • The supplied Markdown /Users/chillishark/ARR项目0727/outputs/res_comment_20260727/RES_COMMENT_TYPE_OF_ROOM.md matches the dedicated fixed Booking Markdown importer: SHA-256 ec2302170c5657d3e465691997e17f7694eb5a7f76feba7e43261632209b8c23, 867 rows, six source worksheets and 348 distinct Group Codes. The controlled database already contains an accepted/current batch with the same hash and counts, so re-importing this exact file is unnecessary and would be idempotent.
  • After the fallback change, the same read-only July 31 preview produced:
    • LianTai: invalid; 136 candidate rows, including 120 blank Booking Rooms; two present Group Codes (LLT260719MA, LT260718KC) still lack accepted Booking matches; two multi-price review warnings remain.
    • QBD: valid; 139 rows, including 128 blank Booking Rooms; four multi-price review warnings.
    • DY-AI-Easy-KB: valid; one row with blank Booking Room.
    • FengRun: valid; 33 rows with blank Booking Room.
    • HanaTour: valid; three rows with blank Booking Room.
  • At that intermediate step, a source/business error still blocked only the affected company while warning-only reports could publish, making four companies publishable and leaving only LianTai blocked.
  • The user then explicitly broadened the rule: both an absent Group Code and a present Group Code with no resolvable Booking room leave Booking Room blank. Processor 1.2.0 keeps a present code's normal (Group Code, ARRIVAL, DEPARTURE) aggregation and Finance pricing; lookup absence alone creates no error or warning.
  • The post-change repeatable-read July 31 preview is valid 5/5 with zero errors:
    • LianTai: 138 rows, 122 blank Booking Rooms and two existing non-blocking multi-price warnings.
    • QBD: 139 rows, 128 blank Booking Rooms and four existing non-blocking multi-price warnings.
    • DY-AI-Easy-KB: one row/one blank; FengRun: 33/33 blank; HanaTour: three/three blank.
  • The current Finance projection also contains one local_fixture/synthetic.xml QBD fact with C/O 2026-07-30. The company-report source does not filter by storage provider, so the month-end snapshot includes that fact.
  • The final scoped company/Booking/report suite ran 32 tests successfully with three expected private-fixture skips; real artifact-tool coverage included five-company XLSX generation, workbook reopen/value validation, rendering and a dedicated end-to-end blank-Booking-Room case. Four Web company-task coordinator tests also passed. No database import, report publication or Finance mutation was performed.
  • The historical port-8766 Web process started at 17:13:54 +08, after the company-report core file's 17:10:03 +08 change; it loaded the earlier no-code-only fallback. Processor 1.2.0 was written at 17:34:13 +08 and was not loaded in that superseded process.
  • Processor 1.2.0 passed 37 company/Booking/real-XLSX/Web-coordinator tests with three expected private-fixture skips. The real builder exported, reopened and value-checked both absent-code and present-but-unmatched blank cells.
  • A non-publishing real-data vertical slice loaded the controlled July 31 snapshot in a repeatable-read/read-only transaction and built all five workbooks in a temporary directory. All five exported, reopened, value-checked and rendered three previews; row counts were 138, 139, 1, 33 and 3 respectively. The temporary artifacts were removed automatically and no report/database state changed.
  • The authenticated replacement runtime now loads current source and reports company_reports_ready=true; activation preserved three existing job records and deliberately did not submit a new report job.
  • A later 2026-07-31 read-only audit first found 014 absent, then observed a concurrent 014/015 deployment at 11:19. Batch 1 is now the explicit current source and draft tables are empty. Port 8766 restarted at 11:30 with Booking source-upload readiness and PATCH/DELETE transport active. Historical fixture reads and processor readiness remain valid. See the later Booking extraction-program evidence.

Finding

The supplied Markdown is a valid Booking source and its historical accepted rows remain queryable. Processor 1.2.0 makes both absent and unresolved Booking enrichment non-blocking and the current July projection previews valid 5/5. LLT260719MA and LT260718KC remain visible business codes with blank Booking Room rather than report errors. The processor runtime and Booking upload/source gate are active. A controlled real draft activation and one released populated company-report job are still required before validating the new end-to-end flow. No additional Booking content is required for the historical lookup baseline.

Impact

  • Do not interpret the two zero-row successful jobs as proof that the month-end data set is publishable.
  • Current Web jobs use the activated processor 1.2.0 runtime, but readiness alone is not proof of a published 5/5 run.
  • Retire the known fixture from the current projection without deleting immutable history before treating a July month-end company report as clean business output.

Open Items

  • Accept one controlled Booking review activation, then run one month-end Web job after the 2026-08-01 00:00 Bangkok release boundary; verify all five downloads and their registered hashes.