Query a Yardi Voyager table and a good chunk of the columns that matter most won't hand you a readable value. They'll hand you a number, or a one-to-two-character code, with no indication anywhere in the row of what it means. iStatus = 2. iType = 5. xtype = 'U'. Every one of these compiles fine, filters fine, and returns an answer whether or not you've decoded it correctly — which is exactly what makes a wrong decode so dangerous. There's no error to catch it. There's just a report that's silently wrong from the moment the filter was written until someone reconciles it against a source they trust more.
Why enum decoding is a data-corruption risk, not a lookup inconvenience
Most schemas that use integer status codes ship a decoder table you can join against — SELECT label FROM status_lookup WHERE code = ?. Voyager mostly doesn't. Its enum decodes exist as UNION-ALL literal views scattered through the schema (tenstatus, ObjectType, Books, and dozens of others), which means the decode is discoverable if you know which view to look at, but nothing forces a query author to look at it before filtering on the raw code. Write iType = 6 believing it means one thing when it means another, and the query still runs, the report still generates, and the number goes out looking exactly as confident as a correct one would.
That's the core risk: enum-coded fields don't fail when misread, they corrupt silently. A rent roll built on a wrong iStatus filter doesn't error — it just quietly includes tenants it should exclude, or excludes ones it should include, and the mistake propagates into every downstream number built on top of that report.
The categories of enum decode that actually exist in Voyager
Rather than list individual code values you'd have to re-verify anyway, it's worth knowing the shape of the problem — the categories of decoder Voyager carries, so you know what to check before trusting a raw code. The schema knowledge base behind the SQL Query Assistant materializes install-invariant enum decodes across 32 decoders and 228 individual code-to-label rows, spanning several distinct categories:
- Tenant and lease lifecycle status —
tenstatusdecodesTENANT.iStatus(current, past, future, eviction, notice, vacant, and related lifecycle states), with commercial and work-order-excluded variants that decode subtly different subsets of the same underlying status field. - The complete
TRANS.iTypemap — the 14-code discriminator that decides whether a posted transaction is a charge, a payment, a deposit, or a record that should be excluded from financial reports entirely. We've written up the full map separately because it's dense enough to deserve its own post — and becauseTRANS.HPERSON's meaning depends on getting this code right first. - The polymorphic
ObjectTyperegistry — the discriminator that governshRecord/hCode-style foreign keys used by attachments, memos, and other polymorphic references across the schema.ObjectTypemaps a single integer to the actual target entity — tenant, property, vendor, unit, purchase order, commercial lease, amendment, and dozens more — because a barehCodevalue is meaningless until you know whichObjectTypeit was written under. - Book codes —
BooksdecodesGLDETAIL.iBook/GLTOTAL.iBook, distinguishing cash-basis postings from accrual-basis ones (and any additional client-defined books beyond the base two), which matters enormously for anyone building trial-balance or GL activity SQL, since cash and accrual postings for the same transaction can both be sitting in the same table. - Commercial deal, amendment, and option status codes — decoders for the commercial-leasing-specific status fields: deal type, amendment type, option status, and proposal status, which follow their own independent code spaces from the tenant lifecycle codes above.
- Property-type and work-order/inspection origin codes — decoders covering
PROPERTY.iTypeand the codes that record where a work order or inspection request originated. - The SQL Server catalog decode —
sysobjects.xtype/sys.objects.type, the underlying database engine's own object-type codes (U= user table,V= view,P= stored procedure, and the rest of the standard catalog set). Useful the moment you're introspecting the schema itself rather than querying business data.
Why "install-invariant" is the load-bearing qualifier
Every decoder in that list is described as install-invariant — meaning the code-to-label mapping is identical across every standard Voyager installation, because it's sourced from Yardi's own shipped decoder views or from the SQL Server catalog, not observed or inferred from any one client's data. That distinction matters because it's what makes a decode safe to trust without re-verifying it against your own database first. A code value that was only ever observed on one install, without a shipped decoder view backing it, doesn't belong in that category — and shouldn't be treated with the same confidence.
What this looks like in practice
Decoding correctly isn't a one-time lookup — it changes what the rest of your query has to check for. Once you know TRANS.iType = 13 marks a system or batch control record, for instance, a correctly scoped financial report has to explicitly exclude it rather than assume every row in TRANS represents a real financial event. The decode isn't just a label; it's the input to a filtering decision the query has to make deliberately.
Stop re-deriving the decode from scratch
The traditional way this knowledge exists is as a private cheat sheet — usually incomplete, usually undocumented, and gone the moment the person who built it moves on. The SQL Query Assistant carries the decode as queryable knowledge instead: ask what a given iStatus, iType, or ObjectType value means on a specific table, and get the verified label back — plus the trap it's attached to, if there is one — directly inside Claude, without spelunking through UNION-ALL view definitions to find it yourself.
It's included in every PropETL tier. Start the free 7-day trial — no credit card — and ask it to decode the next bare integer your query turns up.
