# WP2 — Reopen-for-issue action (Completed → InProcess)

## Goal
Add a "reopen for issue" action that moves a `completed` production order back to `in_process`, so a user can issue the remaining (or, via WP4, over-planned) materials and then re-complete. This fixes orders ALREADY stuck completed with un-issued materials (e.g. PRD-2026-00022) without manual DB edits. Reopen ONLY re-opens the issue door — it reverses NO journals and touches NO stock.

## Exact files
- BE enum: `/home/moonui2/moon-erp-be/Modules/Production/app/Enums/ProductionOrderStatus.php` — transitions map (Completed currently → [Closed] only). Add `Completed → InProcess` as an allowed transition for reopen. Add a `canReopen()` helper (`$this === Completed`). Keep the existing transition map otherwise intact; do NOT allow reopen from Closed.
- BE controller: `/home/moonui2/moon-erp-be/Modules/Production/app/Http/Controllers/ProductionOrderController.php` — add `reopen(ProductionOrder $order)` method mirroring the shape of `complete()` (:314-329): guard `if (! $order->canReopen()) 422`; set `status => InProcess`; return `ProductionOrderResource`. Permission middleware.
- BE routes: `/home/moonui2/moon-erp-be/Modules/Production/routes/api.php` — add `POST production-orders/{order}/reopen` next to the existing complete route. Find the complete route and mirror it.
- BE permission: add `production.orders.reopen` to the Production `RolePermissionSeeder` (or wherever production permissions are seeded — search `production.orders.` in `Modules/Production/database/seeders/`). Grant to the same roles that can complete (admin/production manager). Controller `middleware('permission:production.orders.reopen')` on the reopen method — match how `complete` is permissioned.
- BE i18n: `Modules/Production/lang/{en,ar}/production.php` — message for invalid reopen (`cannot_reopen`).
- FE: `src/app/features/production/orders/production-orders.component.ts` + `.html` — add a "Reopen for issue / إعادة فتح للصرف" button shown when `status === 'completed'` (mirror how the issue/complete buttons are gated at `.html:120-123` list + `:316-319` detail). Calls the service, then refreshes the order.
- FE service: production-order service — add `reopen(id)` POST.
- FE i18n: `src/assets/i18n/{en,ar}.json` `PRODUCTION.ORDERS.REOPEN` etc.

## Behaviour / interface
- `POST /production-orders/{id}/reopen` → if status !== completed → 422 (`cannot_reopen`); else status → in_process, return updated order. No journal entries, no stock movement, no `MaterialIssued` event — pure status flip.
- After reopen the order is `in_process` → `canIssue()` is true → the existing issue button reappears (WP3 makes it clearer). The user issues the remainder, then completes again (WP1 guard applies).

## Acceptance criteria
- Reopen on a completed order → status in_process, no JE created (assert journal_entries count unchanged), issue is possible afterward.
- Reopen on a non-completed order (e.g. in_process, closed) → 422.
- Permission enforced: a user without `production.orders.reopen` → 403.
- FE build green; button visible only on completed orders.

## Tests
- New `ProductionReopenTest.php` (Pest/sqlite): (a) completed order reopen → in_process + zero new journal entries; (b) reopen from in_process → 422; (c) reopen from closed → 422; (d) after reopen, issuing remaining material succeeds and consumed accumulates.
- FE `ng build` green.

## Flags
- [FIN]-adjacent (lifecycle, but NO GL change): reopen must NOT create/reverse journals. Architect-agent review required to confirm no accounting side effects.
- No migration (status column is string; enum change is code-only).

## Interfaces exposed to later WPs
- `canReopen()` on the enum; `reopen()` endpoint; `production.orders.reopen` permission. WP4 relies on an order being reopenable so an over-issue on a completed→reopened order flows through the normal in_process issue path.

## Out of scope
- Do NOT implement over-issue approval (WP4) or touch issue math. Only the status flip + button.