CLAUDE.md — HR Infotype Reader (Global Aggregation Class)

This file is the entry point for Claude Code when working on this project. Read it first. Individual specifications live under specs/.

Project context

The artifact to build is a global, reusable ABAP OO class that reads an arbitrary list of PA infotypes (PA0000, PA0001, PA0002, …) for a single PERNR within a given BEGDA/ENDDA window and returns a time-sliced aggregated table: one row per unique combination of field values across all requested infotypes, with the infotype records nested per row as sub-tables.

Deliverables

Non-negotiable technical rules

These are hard constraints for this codebase. Violations should fail review.

1. Use CL_HRPA_READ_INFOTYPE via IF_HRPA_READ_INFOTYPE, not HR_READ_INFOTYPE. Obtain the instance via CL_HRPA_READ_INFOTYPE=>GET_INSTANCE( IMPORTING infotype_reader = ... ). See specs/infotype_reading_pattern.md.
2. No LDB PNPCE. The class is a utility and must be callable from any context (reports, BAdIs, background jobs, odata artifacts, RAP behaviors). Authorization is handled explicitly via the no_auth_check parameter of IF_HRPA_READ_INFOTYPE->READ / READ_WIDE and the returned missing_auth flag.
3. Two-level buffering is mandatory.
   • Class-level meta cache (GT_META_CACHE, keyed by (infty, molga)) for the T777D/T582V/T582W classification and linkage data that is static per MOLGA.
   • Instance-level PRELP cache (MT_PRELP_CACHE, keyed by (pernr, infty)) for raw read results. Prevents a second physical read for the same employee/infotype within the reader lifetime.
4. Primary vs Secondary dispatch is explicit. Driven by T777D-INFKN: 'I' = primary, 'Z' = secondary. For primary with a linked secondary (resolved via T582V → T582W), use READ_WIDE and cache both rows. For secondary on its own, find the owning primary via T582W → T582V, wide-read the primary, then serve the secondary from cache. Standalone primary uses READ. The top-level READ_AGGREGATED_* methods also auto-expand the caller's IT_INFOTYPES with the linked partner of each entry, so both sides of a primary/secondary pair appear in the result regardless of which side was requested — typed-mode callers must declare T_IT<NNNN> for both (see specs/infotype_reader_spec.md §6.4).
5. PRELP → PNNNN conversion via CL_HR_PNNNN_TYPE_CAST=>PRELP_TO_PNNNN_TAB. Never try to manually un-pack PRELP. The cache stores raw PRELP; the conversion to typed P<NNNN> rows happens at serve time.
6. CX_HRPA_VIOLATED_ASSERTION is the expected framework exception from the reader. Catch it locally and re-raise as ZCX_HR_INFOTYPE_READER with a defined textid and numeric exception code. Never let it escape.
7. MISSING_AUTH is a warning, not an exception. The infotype is skipped, a warning is appended to the message table, processing continues for the remaining infotypes. Raising on auth failure would break batch runs where exactly this scenario is expected for some employees.
8. Constructors do only safe work (field assignments, internal table init). Heavy I/O, authority checks and DB reads belong in explicit methods that can raise exceptions. This aligns with the project convention set by ZCL_HR_XML_*. The class is CREATE PRIVATE; instantiate via ZCL_HR_INFOTYPE_READER=>CREATE( … ).
9. All exceptions are typed — raise ZCX_HR_INFOTYPE_READER with a defined textid and numeric code. Never raise generic CX_ROOT or swallow exceptions silently.
10. Single-responsibility. ZCL_HR_INFOTYPE_READER reads and aggregates. It does not write, log to application log (it returns messages for the caller to log), and does not depend on ZCL_HR_XML_* classes.

Coding standards

• Naming: Z prefix, class ZCL_HR_INFOTYPE_READER, exception ZCX_HR_INFOTYPE_READER.
• Parameters: IV_ / IT_ / IS_ / IR_ for input, EV_ / ET_ / ES_ / ER_ for output, CV_ / CT_ / CS_ for changing, RV_ / RT_ / RS_ / RR_ for returning.
• Internal method parameters may use I_ / E_ / C_ / R_ where brevity helps; public methods always use the full IV_-style prefix.
• Constants: GC_* class-level, LC_* local, upper-snake names.
• Attributes: class-level GT_* / GO_* / GV_*, instance MT_* / MO_* / MV_*.
• All public methods and attributes have ABAP Doc comments ("!).
• Modern ABAP constructor expressions (VALUE, NEW, inline DATA, FOR … IN …, CORRESPONDING) are preferred when readability is equal or better. Classic syntax is fine for database reads where it reads more cleanly.
• Unit tests live in the local test include (ABAP Test Class Unit). Minimum coverage: happy path with one infotype, happy path with multiple infotypes requiring time-slicing, primary+secondary pairing (wide read), invalid PERNR, invalid date range, locked records (SPRPS handling), structure mismatch in typed-mode call, buffer-hit path, missing_auth warning path.

Tooling

abap-docs MCP server

This project uses the abap-docs MCP server as the authoritative reference for SAP class and interface signatures, BAdI definitions, and DDIC types. Claude Code must query abap-docs before hand-writing signatures for any standard SAP object:

• CL_HRPA_READ_INFOTYPE and its interface IF_HRPA_READ_INFOTYPE (methods READ, READ_WIDE, GET_INSTANCE)
• CL_HR_PNNNN_TYPE_CAST (PRELP_TO_PNNNN_TAB)
• CL_HRPA_TCLAS (constants TCLAS_EMPLOYEE etc.)
• CX_HRPA_VIOLATED_ASSERTION
• DDIC types: PRELP, PRELP_TAB, HRPAD_INFOTYPE_DATA_TAB, T777D, T582V, T582W, P<NNNN> structures
• Polish-specific infotype structures: P0515, P0528, P0557, P0558, P0569

If a signature returned by abap-docs conflicts with what appears in a spec, the abap-docs result wins — update the spec and flag the change in the commit message.

Configure in .mcp.json / claude_code_config.json at the project root. The server name used in prompts is abap-docs.

How Claude Code should approach changes

• When asked to implement or modify a method, first open the corresponding spec under specs/. If behavior is not covered by the spec, stop and ask rather than inferring.
• When a spec and the code disagree, the spec is the source of truth unless the user explicitly overrides it. In that case, update the spec in the same change.
• When introducing a new infotype into an existing implementation, verify with abap-docs whether P<NNNN> exists as a DDIC structure and check its T777D-INFKN classification. Customer infotypes (9000–9999) may need custom metadata handling if they are not represented in T582V/T582W.
• Preserve the distinction between "hard error" (raise ZCX_HR_INFOTYPE_READER) and "soft warning" (append to ET_MESSAGES and continue). See specs/exception_class_spec.md for the classification table.

Out of scope for this class

• Writing / modifying / deleting infotype records (INSERT / MODIFY / DELETE operations).
• Cluster data (B2, CU, etc.) and PCL reads.
• OM infotypes (HRP1000, HRP1001, …). A separate OM reader class may reuse this class's patterns but is not in scope.
• Payroll results (PAYxx_RESULT_*).
• Time management infotypes in evaluated form (raw reads of 2001/2002/2003 are fine if requested explicitly — only the evaluation engine is out of scope).
• Multi-PERNR reads. The class reads exactly one PERNR per call. Callers looping over employees instantiate the reader once and reuse the instance — the buffer then works across the loop.