f8cd37ac8c
Includes: API (Express/TypeScript), Astro site, Python workers, document generators, FCC compliance tools, Canada CRTC formation, Ansible infrastructure, and deployment scripts. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
25 lines
1.2 KiB
SQL
25 lines
1.2 KiB
SQL
-- 061: Fix de minimis + safe-harbor factor keying convention
|
|
--
|
|
-- Confusion: the "2026 Form 499-A" is the form released in November 2025
|
|
-- that reports revenue for calendar year 2025. Our UI stores
|
|
-- `form_year = reporting_year` (the year the revenue was earned), which
|
|
-- matches USAC's de-minimis-calculator convention. But migration 054
|
|
-- seeded the row as `form_year=2026` (the form's release year).
|
|
--
|
|
-- Fix: re-key the seed so reporting-year-2025 → factor 0.256. Keep the
|
|
-- 2026 row in place for anyone who keys by form-year; both rows point
|
|
-- at the same factor (since it's just the "filed April 1 2026" factor).
|
|
--
|
|
-- Going forward, the canonical convention is:
|
|
-- form_year = the reporting/revenue year (what the customer picked on
|
|
-- RevenueStep + what the handler stashes in intake.form_year)
|
|
|
|
INSERT INTO fcc_deminimis_factors (form_year, factor, source_citation)
|
|
VALUES (2025, 0.2560, 'For CY2025 revenue — 2026 Form 499-A Appendix A')
|
|
ON CONFLICT (form_year) DO UPDATE SET
|
|
factor = EXCLUDED.factor,
|
|
source_citation = EXCLUDED.source_citation;
|
|
|
|
-- The safe-harbor backfill in migration 058 already covers 2020-2025
|
|
-- at the same values (64.9 / 37.1 / 12.0 / 1.0), so no action needed
|
|
-- for the safe-harbor table.
|