Problem
During extended close, companies keep periods Open but restrict module access to specific user groups. Many posting processes only trigger the auto-update of posting dates when the period is On hold. This mismatch leads to downstream posting errors and manual corrections.
Proposal
Introduce a new ledger period status (e.g., In Closing) that:
- Triggers the same automatic date update logic used when a period is On hold.
- Restricts access to selected modules based on legal entity–specific templates that auto‑apply when a period is set to the new status.
Details
1) New Status
- Status name: In closing (between Open and On hold).
- Behavior:
- Keeps the period open for designated user groups/modules.
- Triggers auto-update of posting dates to the next open period, consistent with On hold logic.
2) Legal Entity–Specific Templates (Auto‑Apply)
Add a new configuration concept: Period Status Templates that define module access rules per legal entity for the new status.
3) Runtime Behavior
- When a period is switched to In closing:
- The matching template for that legal entity is automatically located and applied.
- The system enforces access to each module per the template lines (who can post vs. inquiry‑only).
- Auto‑date roll logic is enabled for invoice/posting processes (same behavior as On hold).
- When the period leaves In closing (to Open or On hold):
- Access reverts to standard module permissions (pre‑status state) or follows a configured reversion rule (template setting: Revert to baseline vs. Retain changes).
Example
- Legal entity: USMF
- Template: “USMF Month‑End In closing”
- AP/AR/Project: Post allowed for Finance Close group; Read‑only for others
- Inventory, Sales, Production: Blocked for all except Ops Close group (Read‑only)
- GL: Post allowed for Controllers only
- When USMF Period 01 is set to In closing, those rules apply immediately and invoice/posting auto-update runs.
3) Scheduled Automation (Batch Job) — New
Provide a batch job to automatically set period status to In closing. This is defined per legal entity but can run for multiple legal entities in one batch execution.
Batch job name (suggested)
- Period Status Auto‑Setter
Parameters
- Legal entity scope:
- Selected legal entities (multi-select) or All legal entities
- Target status: In closing
- Target period selection:
- Current open period (dynamic)
- Next period / Previous period (relative)
- Specific period (lookup by calendar/period ID)
- Timing rules (choose one):
- Specific date/time
- Relative to period boundary (e.g., “Last day of period at 18:00”, “First day + 1 business day at 08:00”)
- Offset (e.g., period end – 4 hours)
- Prerequisite checks :
- Require template exists for each legal entity
- Block if status != Open (prevent accidental overrides)
4) Backward Compatibility
- No impact to existing Open, On hold, Permanently closed logic.
- If no template exists, behavior defaults to current model (only access restrictions configured elsewhere apply; auto-update still triggers due to status).
Acceptance Criteria
- ✅ New In closing status is selectable between Open and On hold.
- ✅ When set to In closing, auto-update of posting dates runs for affected processes the same that On hold currently has
- ✅ A template can be defined per legal entity to control module access and auto‑applies on status change.
· ✅ Batch job exists to automatically set periods to In closing:
- Configurable per legal entity, runnable across multiple legal entities in one batch.
- Supports recurrence, relative timing, and prerequisite checks