# Bug ticket — stock-issue line maps misalign after removing a middle row

**Project:** 283 (مون 2 حسابات) · **Type:** bug · **Priority:** normal · **Screen:** أذون الصرف → «تعديل إذن الصرف»
**Discovered:** 2026-07-19, during the ISS-2026-9166 R3 code review (flagged as a pre-existing deferral).
**Status:** cannot be created via portal API (no create endpoint) — paste the body below into the portal «إصدار جديد» form. Local tracking + fix here.

---

## Paste-ready portal body (bilingual)

**Title / العنوان:** صرف مسلسلات/دفعات خاطئة عند حذف صف من نص جدول إذن الصرف

**EN.** On the Stock Issues «تعديل إذن الصرف» dialog, the per-row **selected serial numbers** and **lot (batch) allocations** are stored in maps keyed by the row's position (index). When you delete a row that is **not the last one**, every row below it shifts up by one position, but those maps are not shifted with them. As a result the serials / lot-allocations stay attached to the old positions and, on save, get submitted for the **wrong rows** — a serial-tracked or batch-tracked item can be issued with another line's serials/lots. Rows added/removed only at the end are unaffected. The on-hand «stock» badge had the same index-shift issue and is fixed in the same change.

**AR.** في ديالوج «تعديل إذن الصرف»، أرقام **المسلسلات المختارة** و**تخصيصات الدفعات (اللوط)** لكل صف بتتخزن في خرائط مفهرسة بموضع الصف (index). لما تحذف صفًا **مش الأخير**، كل الصفوف اللي تحته بتتحرك خانة لفوق، لكن الخرائط دي مابتتحركش معاها — فالمسلسلات/التخصيصات بتفضل معلّقة على المواضع القديمة، وعند الحفظ بتتبعت **لصفوف غلط**، يعني صنف بمسلسل/دفعة ممكن يتصرف بمسلسلات/دفعات صنف تاني. الصفوف اللي بتتضاف/تتحذف من الآخر بس مش متأثرة. بادج «المخزون» كان عنده نفس المشكلة واتظبط في نفس التعديل.

**Steps to reproduce:** افتح مسودة إذن صرف فيها ≥3 أصناف بعضها serial/batch → خصّص مسلسلات/دفعات لصف تاني وتالت → احذف الصف الأول → احفظ → المسلسلات/الدفعات بتطلع على الصنف الغلط.

**Expected:** المسلسلات/الدفعات تفضل مع صنفها بعد الحذف.

---

## Root cause (confirmed)

`stock-issues.component.ts`:
- `rowSelectedSerials = signal<Record<number, string[]>>` (L104) and `rowLotAllocations = signal<Record<number, IssueLotAllocation[]>>` (L107) are keyed by **row index**.
- Submit (`onSave`, L334-343) reads them by the line loop's current `idx` → `getSelectedSerials(idx)` and `rowLotAllocations()[idx]` → into `lineItem.serial_numbers` / `lineItem.lot_allocations`.
- `removeItem(index)` (L743) called `itemsArray.removeAt(index)` **without** shifting the maps. Comment at ~L1159 called this "accepted consciously" — but it silently posts wrong serials/lots on mid-list removal.

## Fix

`removeItem` now reindexes every row-index-keyed map (drop the removed key, shift keys `>` removed down by one) via a shared `reindexRowMap` helper — applied to `rowSelectedSerials`, `rowLotAllocations`, and `stockQtyMap` (replacing R3's full-reload). Stale comment updated.

Display-only maps aside, this corrects the **submitted payload**, so it is a data-correctness fix.

---

## Status — DONE (local), awaiting portal ticket creation by owner
- **Fix:** `stock-issues.component.ts` `removeItem` reindexes rowSelectedSerials + rowLotAllocations + stockQtyMap via `reindexRowMap`; stale comment updated.
- **Review:** opus code-reviewer APPROVE, 0 findings (reindex byte-for-byte matches FormArray.removeAt; all edge cases + payload consistency verified).
- **Build/deploy:** green → `main-RC6AUPPW.js` on /app.
- **CHANGELOG:** bilingual fix bullet added ([Unreleased], tagged "ISS-2026-9166 follow-up").
- **Portal:** no agent create endpoint (POST /api/issues → 405). Owner to paste the body above into «إصدار جديد»; I'll then attach analysis/verification to that ref.