jti-reports

Read an eSeries Data Dictionary export (.xlsx) to answer domain-model questions offline — does a field exist, what is its exact type and length, what lookup list does it use, what relations and traversals exist from an entity, which widgets are valid there, and how two environments differ. Use this whenever you need the model and there is an export available, and use it *first* rather than clicking through the admin: one file answers in seconds what browsing answers in dozens of page loads. Also use it when a field name is in doubt, when a report or widget returns blank, or when promoting config between environments. If no export has been provided, ask the user for one — it is a single button in the admin (see "Getting an export").

Find your way around the OKDAC/eProsecutor (Sustain/Symphony) eSeries admin and case screens — which left-nav path leads where, the URL pattern for every admin screen, how to jump from a rendered case tab to the config behind it, and which environment you are actually on. Use this whenever you need to reach a screen ("where do I change X", "open the folder view for this tab", "how do I get to Reports Admin", "what's the URL for the rule editor") or when a page 404s, returns "Report with code null cannot be found", or shows unfamiliar config. This is the single home for eSeries navigation: other eSeries skills cover what to do once you are on a screen, not how to get there.

The eSeries (Sustain / Symphony) financial data model, and how to get money numbers out correctly — payments, receipts, allocations to fees and restitution, obligations, balances, pay plans, overpayments, deposits, vouchers and disbursements. Use whenever a task involves an amount: "report on payments collected", "why doesn't this total match the Financials screen", "past due obligations", "receipt shows the wrong amount", or any column named Amount, Paid, Balance, Allocated, Collected or Past Due. Reach for it before writing the query, not after: a total can look plausible and be quietly incomplete — a payment allocates down two branches plus an assessment side, some amount fields are integer cents and some are already dollars, overpayments have two representations, and reversed receipts carry no instruments of their own. Miss any of these and the number is wrong with no error. Pairs with `jasper-reports` for report work; this is the domain knowledge, that is the mechanics.

Build, change, and verify eSeries (Sustain / Symphony) Jasper reports — the Groovy business rule that produces the data, the .jrxml that lays out the page, and the contract between them. Use for any report work: "build a report that shows X", "add a column", "why is this blank", "why does it print null", "the totals don't match the case screen", "rename that field", or a report stack trace. Also use it for a FILE handed over with no instructions — a .jrxml, a *BR*.groovy, or an eSeries config export zip such as FORM-local-2026-08-21.zip — because an upload with no words is itself a request to build the report. Putting a finished report into an environment is a separate concern; this one stops at the finished files. Self-contained: works from exported config alone, no live system access needed. Reach for it even for a one-line change — the expensive failures are silent, a wrong path or missing key empties a column without erroring, and the local harness can't catch that.

Run an eSeries (Sustain / Symphony) Jasper report that already exists, read its output, and diagnose a run that failed or came back wrong. Use for "run this report", "the report is blank", "the column is empty", "Report with code null cannot be found", "the totals don't match the screen", "how do I pass parameters", or a screenshot of a report output tab. This is the layer after the report is built and deployed — it needs no source files, so it is the part of the knowledge that travels without the report corpus. Building the rule and .jrxml is `jasper-reports`; registering and installing them is `report-deployment`.