Skip to content

Add fiscal calendar management and period closing operations#85

Merged
jfrench9 merged 4 commits intomainfrom
feature/improved-fiscal-close
Apr 13, 2026
Merged

Add fiscal calendar management and period closing operations#85
jfrench9 merged 4 commits intomainfrom
feature/improved-fiscal-close

Conversation

@jfrench9
Copy link
Copy Markdown
Member

Summary

Enhances the LedgerClient with comprehensive fiscal calendar and period closing functionalities. This feature introduces new API endpoints, request/response models, and high-level client methods to manage the full lifecycle of fiscal periods — from ledger initialization and schedule management through period closing, reopening, and manual closing entry creation.

Key Accomplishments

New API Endpoints (8 added)

  • initialize_ledger — Bootstrap a ledger with initial entity data and fiscal calendar configuration
  • get_fiscal_calendar — Retrieve the full fiscal calendar with period summaries
  • close_fiscal_period — Close a specific fiscal period, finalizing its entries
  • reopen_fiscal_period — Reopen a previously closed fiscal period for corrections
  • set_close_target — Set the target period for the next closing cycle
  • list_period_drafts — List draft entries pending within a fiscal period
  • create_manual_closing_entry — Create manual closing/adjusting journal entries
  • truncate_schedule — Truncate the fiscal schedule at a given point

New Models (18 added)

  • Request models: ClosePeriodRequest, ReopenPeriodRequest, SetCloseTargetRequest, InitializeLedgerRequest, CreateManualClosingEntryRequest, TruncateScheduleRequest, ManualLineItemRequest
  • Response models: ClosePeriodResponse, FiscalCalendarResponse, FiscalPeriodSummary, InitializeLedgerResponse, DraftEntryResponse, DraftLineItem, PeriodDraftsResponse, TruncateScheduleResponse
  • Enums: CreateManualClosingEntryRequestEntryType, EntryTemplateRequestEntryType

Modified Models & Endpoints

  • ClosingEntryResponse — Expanded with additional fields to support richer closing entry data
  • EntryTemplateRequest — Added entry type support
  • CreateScheduleRequest / InitialEntityData — Extended with new optional fields
  • get_statement — Minor update (removed cash flow statement reference from structure type)
  • CreateStructureRequestStructureType — Removed deprecated cash flow statement variant

Client Extension

  • LedgerClient extended with convenient high-level methods wrapping all new endpoints, providing a clean interface for fiscal calendar operations

Breaking Changes

  • CreateStructureRequestStructureType: The cash flow statement enum variant has been removed. Any consumers referencing this value will need to be updated.
  • ClosingEntryResponse model has been significantly refactored with new/changed fields — consumers deserializing this model should verify compatibility.

Testing

  • Added comprehensive unit tests in tests/test_ledger_client.py (446 lines) covering all new LedgerClient fiscal calendar operations including initialization, calendar retrieval, period close/reopen, draft listing, manual entry creation, close target setting, and schedule truncation.
  • All tests use mocked HTTP responses to validate request construction and response parsing.

Infrastructure Considerations

  • No new external dependencies introduced; all new functionality builds on the existing client/model framework.
  • The 18 new model files and 8 new API endpoint modules increase the package surface area — documentation generation and SDK packaging pipelines should be verified to pick up the new modules.
  • Model registry (models/__init__.py) has been updated to export all new types.

🤖 Generated with Claude Code

Branch Info:

  • Source: feature/improved-fiscal-close
  • Target: main
  • Type: feature

Co-Authored-By: Claude noreply@anthropic.com

- Introduced new methods in the LedgerClient for managing fiscal periods, including `initialize_ledger`, `get_fiscal_calendar`, `set_close_target`, `close_period`, `reopen_period`, and `list_period_drafts`.
- Added corresponding request and response models to support these operations, enhancing the client’s capabilities for fiscal management.
- Updated imports to include new API endpoints related to fiscal calendar operations.

These changes improve the LedgerClient's functionality for handling fiscal periods and streamline the workflow for closing and reopening periods.
- Updated the documentation for the `sync_detailed`, `sync`, `asyncio_detailed`, and `asyncio` functions to clarify that all mechanics are handled by `PeriodCloseService.close()`.
- Removed detailed step-by-step descriptions of the closing process to streamline the documentation and focus on the endpoint's role in authentication and exception handling.

These changes improve the clarity and conciseness of the API documentation related to closing fiscal periods.
…ference

- Modified the documentation for the `sync_detailed`, `sync`, `asyncio_detailed`, and `asyncio` functions to reflect the removal of "cash_flow_statement" from the `structure_type` argument, replacing it with "equity_statement".
- Removed the "CASH_FLOW_STATEMENT" constant from the `CreateStructureRequestStructureType` enum to align with the updated documentation.

These changes ensure consistency between the API documentation and the underlying model definitions.
- Introduced a new test suite for the LedgerFiscalCalendar class, covering methods for initializing the ledger, getting the fiscal calendar, setting close targets, closing and reopening fiscal periods.
- Implemented tests to validate success and error scenarios, ensuring proper handling of HTTP responses and optional parameters.
- Enhanced test coverage for fiscal calendar functionalities, improving the reliability of the LedgerClient's fiscal management capabilities.
@jfrench9 jfrench9 merged commit dde34e0 into main Apr 13, 2026
1 check passed
@jfrench9 jfrench9 deleted the feature/improved-fiscal-close branch April 13, 2026 01:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant