The runbook article in this series ends with a rule I hold firmly: do not update ZX tables with SQL. The fair follow-up question — the one a reader actually asked — is: then how do you update them? This article is the complete answer: every configuration object, the supported path that changes it, and what that path writes underneath.
The principle first, because it explains every row of the tables below. E-Business Tax configuration is not flat data — it is a web. A tax rate points at a status, a jurisdiction, a regime, and an account; a jurisdiction points at TCA geography; a rule points at determining-factor and condition sets; nearly everything is date-effective and translated (_B base plus _TL language rows), and the running engine caches chunks of it. The supported update paths exist because they maintain that entire web on every change — validation, linked rows, translations, cache coherence. A direct UPDATE statement maintains none of it, which is how you get an instance where the screen shows one rate and a credit memo calculates another.
The master table: object → path → tables
Everything below is done from the Tax Managers responsibility unless noted. Navigation is 12.1/12.2 HTML UI paths.
| Object | Supported path | Writes to | When you touch it |
|---|---|---|---|
| Tax regime | Tax Configuration → Tax Regimes | ZX_REGIMES_B/_TL | Rarely — entering a new country/regulatory system; changing regime-level defaults |
| Tax | Tax Configuration → Taxes | ZX_TAXES_B | New tax within a regime (a state adopts a retail delivery fee; a country adds a levy); enabling a tax for transactions |
| Tax status | Tax Configuration → Tax Statuses | ZX_STATUS_B | New taxable-nature bucket (a country introduces a second reduced rate) |
| Tax jurisdiction | Tax Configuration → Tax Jurisdictions | ZX_JURISDICTIONS_B | New city/county/district; correcting geography linkage |
| Jurisdictions, in bulk | The mass-create option against a geography level (create jurisdictions from TCA geography) | ZX_JURISDICTIONS_B, rows per geography element | Initial setup; adopting a new geography level (e.g. turning on county tax) |
| Tax rate | Tax Configuration → Tax Rates — end-date the old row, create the successor | ZX_RATES_B/_TL | Every quarterly rate change — the highest-volume path in this table |
| Tax recovery rate | Tax Configuration → Tax Recovery Rates | ZX_RATES_B (recovery-type rows) | Recovery percentage changes (Canadian GST/HST shops) |
| Tax rules | Tax Configuration → Tax Rules (Guided or Expert entry) | ZX_RULES_B + process-result rows | Applicability changes: a state starts taxing digital services, place-of-supply logic changes |
| Determining factor / condition sets | Advanced Setup Options → Tax Determining Factor Sets / Tax Condition Sets | ZX_DET_FACTOR_TEMPL_B, ZX_CONDITION_GROUPS_B, ZX_CONDITIONS | Building the vocabulary a new rule needs (MOS 1111553.1 is the walkthrough) |
| Party tax profiles | Parties → Party Tax Profiles | ZX_PARTY_TAX_PROFILE | Registrations for legal entities/OUs; supplier/customer tax attributes |
| Exemptions | Products / Parties → Tax Exemptions | ZX_EXEMPTIONS | Certificate lifecycle: new, renewed, expired — all date-effective |
| Fiscal classifications | Products → Product Classifications (and party/transaction equivalents) | ZX_FC_* tables | Mapping items/parties/transactions into rule vocabulary |
| Tax accounts | On each rate/tax → Tax Accounts region | ZX_ACCOUNTS | Liability/recovery account changes — coordinate with GL close |
| Tax zones | Tax Zone Types / Tax Zones | zone tables over HZ_GEOGRAPHIES | Grouped geographies (e.g. EU as a zone) when rules need them |
| Geography itself | Not ZX at all — Trading Community Architecture: Administration → Geography Hierarchy, with file-based import for bulk loads | HZ_GEOGRAPHIES and related TCA tables | Annexations, new incorporations, boundary changes; remember TCA accepts exactly one master geography source |
| Migrated 11i codes | Application Object Library lookups | ZX_INPUT_CLASSIFICATIONS / ZX_OUTPUT_CLASSIFICATIONS lookup values | Retiring old classification codes; adding ones legacy processes still reference |
| Withholding | Not E-Business Tax — Payables setup: special calendar, WHT codes and groups | AP withholding tables | Threshold/rate changes for withholding — a Payables change on every EBS release |
Two navigational realities worth naming. First, the UI enforces order: you cannot create a rate before its status, a status before its tax, a jurisdiction before its geography exists. Frustrating on day one; exactly the discipline you want on year ten. Second, the delete button is nearly useless by design — used objects can only be end-dated, which is the audit trail working as intended.
The three legitimate non-UI paths
1. The Tax Implementation Workbook (12.2 only). An Oracle-delivered Excel workbook — nine worksheets covering the regime-to-rate objects — that you populate offline and upload. It runs the same validation as the UI and lands rows in the same tables, which is what makes it supported where raw SQL is not. For a quarterly cycle of a few dozen rate rows the UI is honestly faster; the workbook earns its keep on implementations, new-country rollouts, and mass jurisdiction/rate loads. On 12.1 it does not exist — which is one of the quiet costs of the frozen release: your bulk path is the UI, so budget the clicks in your maintenance schedule.
2. Mass-creation programs. The jurisdiction mass-create against TCA geography is the big one — point it at a geography level and it generates the jurisdiction rows, correctly linked, in one pass. This is the supported answer to “we just turned on county-level tax and need 3,000 jurisdictions.” Its output is only as good as the geography underneath, which is why the boundary-file discipline in the runbook matters.
3. Partner content loaders. Vertex, Avalara, and ONESOURCE integrations deliver monthly content through their own loaders — that is the supported mechanism those architectures use, and on an unsupported EBS release it keeps working because nothing underneath it changes. The operational duty shifts from entering content to verifying the load: after each cycle, confirm the content version and spot-check one known-changed rate. A partner feed that silently stopped loading in March is indistinguishable from “no rates changed” until the audit.
Where SQL is the right tool
The no-SQL rule is about writes to configuration. Three uses remain not just acceptable but essential:
- Read-only verification. Every check in the runbook — contiguous effective dates in
ZX_RATES_B, engine output inZX_LINES, extract completeness inZX_REP_EXTRACT— is a SELECT. Query freely; that is how you audit what the UI did. - Transaction-side data fixes. When the engine has already written wrong tax lines — a bad
ZX_LINESrow from a since-fixed setup error, a stuck distribution — the correction is a diagnosed, scripted, rollback-capable data fix against transaction tables. That is precisely the third-party-support craft, and it is a different thing from editing what the tax configuration says, which the UI must own. - Pre-change impact analysis. Before a rules change, a SELECT telling you how many open transactions carry the affected classification is the difference between a clean cutover and a surprise.
The boundary in one sentence: SQL to observe and to repair transactions; the application to change configuration. On a supported release that rule saves you SRs. On an unsupported one it saves you from being the person who broke the tax engine with no one left to call.
Facing a bulk change that seems too big for the UI on 12.1 — a new country, a thousand jurisdictions, a rules overhaul? Describe it — there is usually a supported path, and I’ll tell you what it is before you commit to anything.