# Accounting Module — Phase 17 Tasks (Enterprise UAT, Parallel Run ও Full Release)

> এখানকার প্রতিটি task আলাদা করে একজন কাজ করতে পারবে।
> Phase 17-এ কোনো নতুন table নেই। এই অংশের card-গুলো test ও অপারেশন: UAT কৌশল, capability UAT, cross-module end-to-end, negative ও isolation, data migration মহড়া, parallel run, scale ও performance, failover ও DR drill। কোথাও ব্যর্থতা মিললে সংশোধন সংশ্লিষ্ট Phase-এর card-এ, এই Phase-এ নয়।
> ক্রম: UAT কৌশল ও catalog → তিন দলের capability UAT → cross-module E2E ও negative/security → migration মহড়া → parallel run → scale/performance → DR drill।
> Estimate, Owner, Sprint ইচ্ছা করে ফাঁকা রাখা হয়েছে।
> নোট: Phase 17-এর আসলে P17-01 থেকে P17-20 আছে, কিন্তু এই document-এ শুধু P17-01 থেকে P17-10 আছে; P17-11 থেকে P17-20 (release control: go/no-go, wave rollout, hypercare, rollback, governance, penetration test, accessibility, training, support, handover ইত্যাদি), Blueprint ২৭.৯-এর scenario ও traceability table, এবং Phase 7, 9-16-এর card অন্য tab-এ, তাই সেগুলো এখানে বানানো হয়নি।

## সব Phase 17 task-এ প্রযোজ্য সাধারণ নিয়ম (প্রতিটা task নিজের DoD-তে এগুলো ধরে নেয়)

- **Phase 17-এ কোনো product code বা নতুন table নেই।** কাজ হলো পরীক্ষা, প্রমাণ সংগ্রহ ও অপারেশন। কোথাও ব্যর্থতা মিললে সংশোধন সংশ্লিষ্ট Phase-এর card-এ, এই Phase-এ নয়।
- **R17.1 UAT ও production আলাদা।** UAT পরিবেশ = production-copy, মাস্ক করা। সাধারণ API দিয়ে `PostingService` হয়ে লেখা; সরাসরি SQL insert নেই।
- **R17.2 expected result আগে লেখা** (run-এর আগে)। **R17.3 প্রমাণ ছাড়া pass নেই।** **R17.4 প্রতিটা scenario-তে debit = credit নিশ্চিত।**
- **ব্যর্থ হলে ledger হাতে ঠিক করা নিষেধ;** ঠিক করার পথ Reversal বা Adjustment, অথবা snapshot restore (শুধু UAT পরিবেশে)। কোনো পরীক্ষায় trigger বা guard বন্ধ করা যাবে না (Phase 3-এর test পরিবেশের নির্দিষ্ট ব্যতিক্রম ছাড়া)।
- **Scenario ID ফরম্যাট:** `UAT-{phase}.{n}`, `UAT-E{n}`, `UAT-N{n}`, `MIG-{n}`, `PF-{n}`, `DR-{n}`, `PT-{n}`। এগুলোর পূর্ণ তালিকা ও traceability table Blueprint ২৭.৯-এ (এই document-এ নেই)।
- **Defect severity:** sev1 থেকে sev4 (সংজ্ঞা `P17-01`-এ)। Capability UAT-এর শেষে কোনো sev1 বা sev2 খোলা থাকা চলবে না।
- **Persona (seed role):** accountant, approver, AP clerk, AR clerk, treasury, auditor, admin, read-only। Scenario নিজে permission বাদ দেয় না; সব persona আলাদা login।
- **Permission:** `accounting.release.view` (দেখা), `accounting.release.manage` (cycle চালানো); `accounting.release.approve` (accepted exception, `P17-08`)। এগুলো এই document-এর §২.৩ তালিকায় নেই (Enterprise Registry-তে, যা অন্য tab-এ)।
- **Error:** `REL_PRECONDITION_FAILED` (পরিবেশ বা data প্রস্তুত নয়), `REL_PARALLEL_RUN_OPEN` (parallel run exit শর্ত অপূর্ণ)। বাকি সব error সংশ্লিষ্ট capability-র prefix।
- **Audit prefix:** `accounting.release.*` (`uat_cycle_started`, `uat_cycle_signed`, `uat_scenario_result`, `migration_rehearsal_done`, `parallel_run_compared`, `discrepancy_resolved`, `scale_test_done`, `dr_drill_done`)।
- **প্রমাণ জমা:** `acc_reconciliation_runs` (RC1 থেকে RC18), `acc_report_exports`; scenario-র ফল আলাদা সংখ্যা সহ লগ।
- **Phase 5-এর সাথে সম্পর্ক:** এই Phase বিদ্যমান `P5-04` (rollback), `P5-06` (release gate) ও `P5-08` (pilot rollout) বাড়ায়, বদলায় না। Phase 5-এর UAT ফল কোনো DB table-এ নয় (QA tool-এ), কিন্তু এই Phase-এর প্রমাণ `acc_reconciliation_runs` ও `acc_report_exports`-এ।
- **DoD-র সাধারণ অংশ:** scenario-র ফল সংখ্যাসহ লগ; প্রতি scenario-র expected result run-এর আগে লিখিত; sign-off (নির্ধারিত ভূমিকার সই) জমা; defect তালিকা ও triage; কোনো sev1/sev2 খোলা নেই বা অনুমোদিত exception; পরিবেশ আবার snapshot-এ ফেরানো যায়।

**Phase-স্তরের open point (একাধিক card প্রভাবিত):**

- OD-105, OD-105a, OD-105b, OD-107, OD-108, OD-108b, OD-114, OD-115, OD-119, এবং AC17.x (card-এর ভেতরে লেখা), R17.x (R17.9, R17.10, R17.11, R17.18-এর বিষয়বস্তু source-এ লেখা নেই), G9, G17.1 থেকে G17.4, Blueprint ২৭.৯ক থেকে ২৭.৯চ-এর scenario তালিকা এই document-এ নেই।
- RC1 থেকে RC9 `P3-13`-এ সংজ্ঞায়িত; RC10 থেকে RC18 (Phase 7 থেকে 16-এর check) এই document-এ নেই। `RC1d`, `RC1m`, `RC1n` Phase 6-এর sub-check।
- `P17-05` "অবরুদ্ধ করে P17-07" বলেছে কিন্তু `P17-07` তার "নির্ভর করে"-তে `P17-05` রাখেনি (রেখেছে `P17-04`, P16 import card, `P5-02`)।
- `P17-09`-এর lock ক্রম বর্ণনা ("journal, approval, account, period, voucher counter") Phase 6-এর চূড়ান্ত ক্রমের (number series `FOR SHARE`, counter `FOR UPDATE`, শেষে dimension value `FOR SHARE`) চেয়ে ছোট।

**Phase 17 নির্ভরতা-ছবি (এই document-এর P17-01 থেকে P17-10; বাইরের নির্ভরতা বন্ধনীতে):**

```
P5-01,P5-02 + P6..P16 exit gate ─► P17-01 ─┬─► P17-02 (+সব P6..P10) ─┐
                                           ├─► P17-03 (+সব P11..P13) ─┼─► P17-05 ─┬─► P17-08 (+P17-07)
                                           └─► P17-04 (+সব P14..P16) ─┤           ├─► P17-09 (+P17-07, P16 partitioning/archive)
                                                    │                  └─► P17-06  │
                                                    └─► P17-07 (+P16 import, P5-02) ─┘   P17-09 ─► P17-10 (+P16 DR, P5-04)
P17-01 ─► P17-11, P17-12  P17-02..P17-10 ─► P17-15  P17-06 ─► P17-11  P17-07 ─► P17-16  P17-10 ─► P17-19  (সব অন্য tab-এ)
```

---

## ACC-P17-01 — UAT কৌশল, পরিবেশ ও scenario catalog

Project
ERPFlow
Module
Accounting Module
Type
Operations + Test (`ops` + `test`)
Title
UAT কৌশল, পরিবেশ ও scenario catalog
Branch Name
`feature/accounting-uat-strategy-catalog`
View Order
94
Description
**Summary**
UAT শুরু করার আগে একটা কাঠামো দরকার: সব capability একই নিয়মে, একই পরিবেশে, একই প্রমাণের ছাঁচে। scenario catalog, persona, severity, snapshot-নিয়ম — পরের card (দল ক/খ/গ, E2E, negative) আলাদা কাজ হলেও ফল তুলনীয় ও প্রমাণযোগ্য থাকবে।

**Task serial**
`ACC-P17-01 — UAT কৌশল, পরিবেশ ও scenario catalog` · Ops + Test · Phase 17, প্রথম card

**Depends on**
- `ACC-P5-01` (UAT pack ও সই: 14টা পরিস্থিতি U01 থেকে U14)
- `ACC-P5-02` (Cutover মহড়া)
- Phase 6 থেকে 16-এর প্রতিটা exit gate (সব P6 থেকে P16 card সবুজ)। এর মধ্যে এই pack-এর Phase 6 (`ACC-P6-15` enablement ও gate রিপোর্ট) এবং Phase 8 (P8-01 থেকে P8-05) অন্তর্ভুক্ত; বাকি phase অন্য tab-এ।

**Relation: আগের task**
- `P5-01` দিয়েছে Phase 1-5-এর UAT-র পদ্ধতি (ধাপ-ধাপ script, প্রমাণ, defect তালিকা, সই) ও 14টা পরিস্থিতি; এই card সেই পদ্ধতিকে সব capability-র জন্য একটা কাঠামোয় বাড়ায়। 
- `P5-02` দিয়েছে cutover মহড়ার পদ্ধতি (staging, বারবার চালানো, সময় মাপা), যা এই card-এর পরিবেশ ও snapshot-নিয়মের উদাহরণ।
- Phase 6 থেকে 16-এর exit gate: প্রতিটা Phase-এর নিজস্ব test সবুজ হওয়ার প্রমাণ (যেমন `ACC-P6-15`-এর gate রিপোর্ট, RC1d/RC1m/RC1n সবুজ)। সেগুলো না থাকলে UAT শুরু করা যায় না।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-02`, `P17-03`, `P17-04` (capability UAT): এই card-এর scenario ছাঁচ, ID নিয়ম, persona/role, পরিবেশ ও severity সংজ্ঞা ব্যবহার করে।
- `P17-05` থেকে `P17-12`: E2E, negative, migration মহড়া, parallel run, scale, DR ও পরের release-control card (P17-11, P17-12 অন্য tab-এ) একই পরিবেশ ও catalog ধরে।
- `P17-15` (অন্য tab-এ): source এই card-কে নির্ভরতায় রেখেছে।

**Related tables / schema**
নতুন table নেই।
- পড়া: সব `acc_` table (UAT পরিবেশ = production-copy, মাস্ক করা)।
- প্রমাণ জমে: `acc_reconciliation_runs` (RC1 থেকে RC18) ও `acc_report_exports`।

**Business rules**
- R17.1 (UAT ও production আলাদা), R17.2 (expected result আগে লেখা), R17.3 (প্রমাণ ছাড়া pass নেই)।
- লেখা শুধু সাধারণ API দিয়ে, `PostingService` হয়ে। সরাসরি SQL insert নেই।
- প্রতিটা UAT cycle শুরুতে snapshot restore। ব্যর্থ হলে cycle থামে, snapshot-এ ফেরা হয়, ledger-এ আংশিক অবস্থা থাকে না।
- Scenario script ছাঁচ: id, capability, precondition, ধাপ, expected ledger line (account, debit, credit), RC check তালিকা, প্রমাণের লিংক, দায়ী persona।
- Catalog ID: `UAT-{phase}.{n}`, `UAT-E{n}`, `UAT-N{n}`, `MIG-{n}`, `PF-{n}`, `DR-{n}`, `PT-{n}`।
- Persona-র জন্য seed করা role: accountant, approver, AP clerk, AR clerk, treasury, auditor, admin, read-only।
- Defect severity সংজ্ঞা sev1 থেকে sev4 ও blocking নিয়ম (কোনটা gate আটকায়)।
- Traceability: Phase 6 থেকে 16-এর প্রতিটা AC কোনো না কোনো scenario-তে ঢাকা (traceability table-এ খালি ঘর শূন্য)।
- **Open point:** OD-105a, OD-105b (data volume), OD-108 লিখিত সিদ্ধান্ত নেই; "Cycle calendar (কতটা cycle, কখন)" সংখ্যা source-এ নেই (পরের card "Cycle 3"-এর কথা বলে, মানে অন্তত ৩ cycle ধরা হয়েছে)।
- **Open point:** Masking নিয়ম (কোন field কীভাবে মাস্ক), পরিবেশের আকার ও snapshot restore পদ্ধতি source-এ নির্দিষ্ট নেই; সাব-টাস্ক ১ এ ঠিক করতে হবে।
- **Open point:** Permission `accounting.release.view`/`.manage` ও persona role seed কীভাবে (`P1-02`-এর seed কাঠামো বাড়িয়ে নাকি আলাদা) করা হবে source-এ নেই; এগুলো Phase 17-এ "নতুন code নেই" নিয়মের সাথে সংঘাত করতে পারে (seed/config বাদে)।
- **Open point:** Phase 5-এর UAT (QA tool-এ) ও Phase 17-এর প্রমাণ (DB table `acc_reconciliation_runs`, `acc_report_exports`)-এর সমন্বয় কীভাবে (Phase 5-এর 14 পরিস্থিতি catalog-এ ঢুকবে কি না) source বলেনি।

**DB flow**
UAT পরিবেশ = production-copy, মাস্ক করা।
- পড়া: সব `acc_` table।
- লেখা: শুধু সাধারণ API দিয়ে, `PostingService` হয়ে। সরাসরি SQL insert নেই।
- প্রমাণ জমে `acc_reconciliation_runs` (RC1 থেকে RC18) ও `acc_report_exports`-এ।
- প্রতিটা UAT cycle শুরুতে snapshot restore। ব্যর্থ হলে cycle থামে, snapshot-এ ফেরা হয়, ledger-এ আংশিক অবস্থা থাকে না।

**Task scope**
1. পরিবেশ ও data masking নিয়ম।
2. Persona ও role seed।
3. Scenario ছাঁচ ও ID নিয়ম।
4. Defect severity ও blocking নিয়ম।
5. Cycle calendar (কতটা cycle, কখন)।
6. Traceability table ভরা (Phase 6 থেকে 16-এর প্রতিটা AC → scenario)।

**Out of scope**
আসল scenario script লেখা ও চালানো (`P17-02` থেকে `P17-04`)। E2E ও negative (`P17-05`, `P17-06`)। Release-control, go/no-go (`P17-11` ইত্যাদি, অন্য tab)।

**Contract (API)**
Scenario script ছাঁচ: id, capability, precondition, ধাপ, expected ledger line (account, debit, credit), RC check তালিকা, প্রমাণের লিংক, দায়ী persona। Catalog-এর ID: `UAT-{phase}.{n}`, `UAT-E{n}`, `UAT-N{n}`, `MIG-{n}`, `PF-{n}`, `DR-{n}`, `PT-{n}`। (নতুন HTTP endpoint source-এ নেই।)

**Permission**
`accounting.release.view` (দেখা), `accounting.release.manage` (cycle চালানো)। প্রতি persona-র জন্য seed করা role: accountant, approver, AP clerk, AR clerk, treasury, auditor, admin, read-only।

**Error**
`REL_PRECONDITION_FAILED` (পরিবেশ বা data প্রস্তুত নয়)

**Audit**
`accounting.release.uat_cycle_started`, `accounting.release.uat_cycle_signed`

**Acceptance**
AC17.1: catalog-এ প্রতিটা capability-র অন্তত একটা scenario। AC17.2: প্রতিটা scenario-র expected result লেখা আছে run-এর আগে।

**Test**
Catalog completeness check: P6 থেকে P16-এর প্রতিটা AC কোনো না কোনো scenario-তে ঢাকা (traceability table খালি ঘর শূন্য)।

**Deliverable**
UAT কৌশল doc, পরিবেশ বিবরণ, persona ও role তালিকা, scenario ছাঁচ, catalog, defect severity সংজ্ঞা (sev1 থেকে sev4)

**Sub-tasks**
1) পরিবেশ ও data masking নিয়ম। 2) Persona ও role seed। 3) Scenario ছাঁচ ও ID নিয়ম। 4) Defect severity ও blocking নিয়ম। 5) Cycle calendar (কতটা cycle, কখন)। 6) Traceability table ভরা

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.1, AC17.2 সবুজ; traceability table-এ খালি ঘর শূন্য।
- UAT পরিবেশ production থেকে আলাদা প্রমাণিত; snapshot restore একবার পরীক্ষিত।
- Persona দিয়ে আলাদা login কাজ করে।

**Architecture constraints**
- UAT পরিবেশ production-এর সাথে কখনো মেশে না; data মাস্ক করা।
- সরাসরি SQL insert নয়; সব লেখা API ও `PostingService` দিয়ে।
- কোনো product code বা table নয়।

Owner
Dev C
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-02 — Capability UAT script, দল ক (journal, FX, tax, subledger, bank)

Project
ERPFlow
Module
Accounting Module
Type
Test (`test`)
Title
Capability UAT script, দল ক (journal, FX, tax, subledger, bank)
Branch Name
`feature/accounting-uat-group-a`
View Order
95
Description
**Summary**
দল ক: journal management ও dimensions, multi-currency, tax, subledger, bank — প্রতিটার scripted scenario লেখা ও চালানো (expected ledger line ও RC সহ)। production-এর মতো UAT পরিবেশে এই ক্ষমতাগুলো প্রমাণিত হবে।

**Task serial**
`ACC-P17-02 — Capability UAT script, দল ক (journal, FX, tax, subledger, bank)` · Test · Phase 17, দ্বিতীয় card

**Depends on**
- `ACC-P17-01`
- সব P6, P7, P8, P9, P10 card। এই pack-এ: Phase 6 (`ACC-P6-01` থেকে `ACC-P6-15`) ও Phase 8-এর P8-01 থেকে P8-05; Phase 7, 9, 10 এবং P8-06 থেকে P8-18 অন্য tab-এ।

**Relation: আগের task**
- `P17-01` দিয়েছে পরিবেশ, scenario ছাঁচ, ID নিয়ম, persona/role, severity সংজ্ঞা ও cycle calendar।
- Phase 6 (journal management ও dimensions): `P6-15` gate সবুজ, দুই flag (`journal_mgmt.enabled`, `dimensions.enabled`) চালু করার সক্ষমতা। UAT-6.x scenario এই card-এ লেখা হয়; Phase 6 card-গুলোর Test অংশ ও G6.x/AC6.x ওই scenario-র উৎস।
- Phase 8 (tax): `P8-01` থেকে `P8-05`: jurisdiction, code, rate, group, account map ও `TaxService`। UAT-8.x এগুলো ও পরের Phase 8 card (অন্য tab) চালায়।
- Phase 7, 9, 10: অন্য tab-এ; এদের সংজ্ঞা এই document-এ নেই।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-05` (cross-module E2E): দল ক-এর scenario পাস না হলে E2E-র জোড়া পরীক্ষা অর্থহীন।
- `P17-06` (negative ও isolation): source `P17-06` কে এই card-এর ওপর নির্ভরশীল রেখেছে (P17-02, 03, 04 তিনটাই)।
- `P17-15` (অন্য tab-এ)।

**Related tables / schema**
নতুন table নেই। পড়া:
- `acc_journals`, `acc_journal_lines`, `acc_journal_line_dimensions` (`P6-09`), `acc_journal_line_taxes` (Phase 8-এর শেয়ার্ড table, এই document-এ নেই), `acc_period_balances`।
- RC চালানো: RC10, RC12, RC13, RC14 (Phase 7-10-এর check, সংজ্ঞা এই document-এ নেই) এবং প্রযোজ্য হলে RC1 থেকে RC9, `RC1d`, `RC1m`, `RC1n`।

**Business rules**
- R17.2, R17.3, R17.4 (প্রতিটা scenario-তে debit সমান credit নিশ্চিত)।
- প্রতিটা scenario: precondition data API দিয়ে বসানো, ক্রিয়া চালানো, তারপর পড়া ও তুলনা: লিখিত expected line বনাম ledger।
- কোনো লেখা সরাসরি নয়।
- ব্যর্থ হলে defect রেকর্ড; ledger হাত দিয়ে ঠিক করা নয়, Reversal বা Adjustment দিয়ে।
- Negative case-এ প্রত্যাশিত error code capability-র prefix-সহ (JTY_, DIM_, FX_, TAX_, PTY_, OPI_, BNK_)।
- Scenario নিজেই permission বাদ দেয় না; persona role অনুযায়ী।
- **Open point:** UAT-6.x থেকে UAT-10.x scenario তালিকা Blueprint ২৭.৯ক-এ; এই document-এ নেই, তাই scenario-র ঠিক সংখ্যা ও expected সংখ্যা এখানে নেই।
- **Open point:** Error prefix `FX_`, `PTY_`, `OPI_`, `BNK_` Phase 7, 9, 10-এর (অন্য tab), সংজ্ঞা অজানা। RC10, RC12, RC13, RC14 কোন capability-র তা সংজ্ঞা-অভাবে অনুমান (Phase 7-10)।
- **Open point:** "কোনো sev1 বা sev2 খোলা নেই" এ অনুমোদিত exception-এর প্রক্রিয়া (কে অনুমোদন দেবে) source-এ নেই।

**DB flow**
প্রতিটা scenario:
1. Precondition data API দিয়ে বসানো।
2. ক্রিয়া চালানো।
3. তারপর পড়া: `acc_journals`, `acc_journal_lines`, `acc_journal_line_dimensions`, `acc_journal_line_taxes`, `acc_period_balances`।
4. তুলনা: লিখিত expected line বনাম ledger।
5. RC10, RC12, RC13, RC14 চালানো।

কোনো লেখা সরাসরি নয়। ব্যর্থ হলে defect রেকর্ড, ledger হাত দিয়ে ঠিক করা নয়, reversal বা adjustment দিয়ে।

**Task scope**
1. Phase 6 scenario (journal type, numbering/gapless, backdate, template, import, সংযুক্তি, dimension, reclass, report filter)।
2. Phase 7 scenario (multi-currency ও FX)।
3. Phase 8 scenario (tax)।
4. Phase 9 scenario (subledger AR/AP ও party)।
5. Phase 10 scenario (bank ও cash)।
6. Defect triage ও পুনরায় চালানো।

**সহায়ক ছক (এই pack-এর card থেকে বের করা, source-এর UAT তালিকা নয়):** Phase 6/8 scenario লেখার সময় নিচের card-এর Test, AC ও golden-কে উৎস ধরা যায়।

| Capability | উৎস card | AC / golden |
| --- | --- | --- |
| Journal type ও আচরণ | `P6-01`, `P6-02` | AC6.1, AC6.2, AC6.5 |
| Number series, gapless, cutover | `P6-03`, `P6-04` | AC6.3, AC6.4, AC6.5, G6.1, G6.2 |
| Document/backdate | `P6-05` | AC6.2, G6.8 |
| Template | `P6-06` | AC6.6, G6.9 |
| Bulk import | `P6-07` | AC6.7, G6.7 |
| সংযুক্তি, comment, tag, copy, search | `P6-08` | AC6.13 |
| Dimension কাঠামো, rule, balancing | `P6-09`, `P6-10` | AC6.8, AC6.9, G6.3, G6.4, G6.5 |
| Dimension value ও mirror | `P6-11` | AC6.11 |
| Reclassification | `P6-12` | AC6.10, G6.6 |
| Report filter | `P6-13` | AC6.12, G6.10 |
| Tax jurisdiction, code, rate | `P8-01`, `P8-02` | AC8.1, AC8.2, AC8.3 |
| Tax group, account map | `P8-03`, `P8-04` | AC8.4, AC8.5 |
| Tax গণনা | `P8-05` | AC8.6, AC8.7, AC8.8 |

**Out of scope**
Scenario catalog কাঠামো (`P17-01`)। দল খ ও গ (`P17-03`, `P17-04`)। Cross-module পথ (`P17-05`)। Defect-এর কোড সংশোধন (সংশ্লিষ্ট Phase-এর card)।

**Contract (API)**
Blueprint ২৭.৯ক-এর scenario তালিকা (UAT-6.x থেকে UAT-10.x)।

**Permission**
Persona role অনুযায়ী। Scenario নিজেই permission বাদ দেয় না।

**Error**
সংশ্লিষ্ট capability-র error code (`JTY_`, `DIM_`, `FX_`, `TAX_`, `PTY_`, `OPI_`, `BNK_`) প্রত্যাশিত negative case-এ।

**Audit**
`accounting.release.uat_scenario_result`

**Acceptance**
AC17.3: দলের সব scenario pass বা অনুমোদিত exception। কোনো sev1 বা sev2 খোলা নেই।

**Test**
নিজেই test। প্রতিটা চালানোর ফল আলাদা সংখ্যা সহ লগ।

**Deliverable**
চালানো scenario-র ফল, defect তালিকা, accountant-এর সই

**Sub-tasks**
1) Phase 6 scenario। 2) Phase 7। 3) Phase 8। 4) Phase 9। 5) Phase 10। 6) Defect triage ও পুনরায় চালানো

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.3 সবুজ: সব scenario pass বা অনুমোদিত exception; sev1/sev2 খোলা নেই।
- প্রতি scenario-র expected line run-এর আগে লিখিত ও debit = credit যাচাই।
- Accountant-এর সই জমা।

**Architecture constraints**
- ledger হাতে ঠিক করা নিষেধ; Reversal/Adjustment বা snapshot restore।
- সরাসরি SQL লেখা নেই।
- Scenario permission এড়ায় না।

Owner
Dev A
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-03 — Capability UAT script, দল খ (fixed asset, period-end ও year-end, budgeting ও reporting)

Project
ERPFlow
Module
Accounting Module
Type
Test (`test`)
Title
Capability UAT script, দল খ (fixed asset, period-end ও year-end, budgeting ও reporting)
Branch Name
`feature/accounting-uat-group-b`
View Order
96
Description
**Summary**
দল খ: fixed asset, recurring/deferral/allocation, close checklist, year-end, budget, forecast, report designer, KPI — scripted scenario, expected result, চালানো। period-end থেকে management reporting পর্যন্ত সব ঢাকা পড়বে।

**Task serial**
`ACC-P17-03 — Capability UAT script, দল খ (fixed asset, period-end ও year-end, budgeting ও reporting)` · Test · Phase 17, তৃতীয় card

**Depends on**
- `ACC-P17-01`
- সব P11, P12, P13 card (Fixed asset, period-end/recurring/year-end, budgeting/forecast/management reporting; সবই অন্য tab-এ, এই document-এ নেই)

**Relation: আগের task**
- `P17-01` দিয়েছে পরিবেশ, ছাঁচ, persona, severity, snapshot-নিয়ম (year-end scenario আলাদা snapshot-এ)।
- Phase 11 (Fixed Asset Accounting), Phase 12 (Period-End, Recurring, Year-End), Phase 13 (Budgeting, Forecast, Management Reporting): এই card-এর মূল ইনপুট; তাদের কোনো card এই document-এ নেই। Phase 12-এর recurring Phase 6-এর template (`ACC-P6-06`) ব্যবহার করে বলে `P6-06` এর ফল পরোক্ষে এই card-এর recurring scenario-র ভিত্তি (source-এ সরাসরি বলা নেই)।
- `P3-11` (Period বন্ধ), `P3-12` ও `acc_period_events` (Phase 3): close checklist ও period events পড়ার ভিত্তি।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-05` (E2E): E3 পথে (asset acquisition, depreciation, disposal) ও E1 পথে (period close, year-end) এই দলের ক্ষমতা জোড়া লাগে।
- `P17-06` (negative) ও `P17-15` (অন্য tab-এ)।

**Related tables / schema**
নতুন table নেই। পড়া: `acc_journals`, `acc_journal_lines`, `acc_period_balances`, `acc_periods`, `acc_period_events`। RC চালানো: RC11, RC16, RC17 (Phase 11, 12, 13-এর check; সংজ্ঞা এই document-এ নেই) ও RC1।

**Business rules**
- R17.2, R17.4, R17.5 (year-end scenario সবসময় snapshot-এ)।
- চালানো সব API ও job দিয়ে (`AccountingJob`)।
- Year-end scenario আলাদা snapshot-এ, কারণ ফেরানো যায় না।
- ব্যর্থ হলে snapshot restore, ledger হাতে ঠিক নয়।
- Year-end carry-forward-এর পর opening balance = আগের closing balance (RC1)।
- Negative case-এ প্রত্যাশিত error prefix: FA_, PER_, REC_, DEF_, ALC_, YER_, BUD_, RPD_।
- Year-end scenario দুইবার চালানো (একবার snapshot থেকে, ফল একই কিনা)।
- **Open point:** UAT-11.x থেকে UAT-13.x scenario তালিকা Blueprint ২৭.৯ক-এ, এই document-এ নেই। "OD: কোনোটি নয়" লিখিত।
- **Open point:** RC11, RC16, RC17 ও error prefix-গুলো (FA_, PER_, REC_ ইত্যাদি) অন্য tab-এ সংজ্ঞায়িত; এই card-এ অনুমানে কিছু ধরা নিষেধ।
- **Open point:** Year-end scenario "ফেরানো যায় না" (production-এ), তাই snapshot-ভিত্তিক; দ্বিতীয়বার চালানোর "একই ফল" তুলনার মানদণ্ড (কোন সংখ্যা/hash) source-এ নেই।

**DB flow**
- পড়া: `acc_journals`, `acc_journal_lines`, `acc_period_balances`, `acc_periods`, `acc_period_events`।
- চালানো সব API ও job দিয়ে (`AccountingJob`)।
- Year-end scenario আলাদা snapshot-এ, কারণ ফেরানো যায় না।
- RC11, RC16, RC17 চালানো।
- ব্যর্থ হলে snapshot restore, ledger হাতে ঠিক নয়।

**Task scope**
1. Phase 11 scenario (fixed asset)।
2. Phase 12 scenario (recurring, deferral, allocation, close checklist); year-end আলাদা snapshot-এ।
3. Phase 13 scenario (budget, forecast, report designer, KPI)।
4. Defect triage ও পুনরায় চালানো।

**Out of scope**
দল ক ও গ (`P17-02`, `P17-04`)। Cross-module E2E (`P17-05`)। Production year-end কার্যক্রম।

**Contract (API)**
Blueprint ২৭.৯ক-এর UAT-11.x থেকে UAT-13.x।

**Permission**
Persona role অনুযায়ী।

**Error**
`FA_`, `PER_`, `REC_`, `DEF_`, `ALC_`, `YER_`, `BUD_`, `RPD_` প্রত্যাশিত negative case-এ।

**Audit**
`accounting.release.uat_scenario_result`

**Acceptance**
AC17.3: দলের সব scenario pass বা অনুমোদিত exception। Year-end carry-forward-এর পর opening balance = আগের closing balance (RC1)।

**Test**
নিজেই test। Year-end scenario দুইবার চালানো (একবার snapshot থেকে, ফল একই কিনা)।

**Deliverable**
ফল, defect তালিকা, accountant ও controller-এর সই

**Sub-tasks**
1) Phase 11 scenario। 2) Phase 12 scenario, year-end আলাদা। 3) Phase 13 scenario। 4) Defect triage ও পুনরায় চালানো

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.3 সবুজ; year-end carry-forward-এর RC1 সবুজ।
- Year-end দুইবার চালিয়ে ফল অভিন্ন।
- Accountant ও controller-এর সই জমা।

**Architecture constraints**
- Year-end scenario কখনো স্থায়ী পরিবেশে নয়; সবসময় আলাদা snapshot।
- ledger হাতে ঠিক করা নিষেধ।
- Job চালানো `AccountingJob` base ধরে।

Owner
Dev B
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-04 — Capability UAT script, দল গ (posting rules, integration, consolidation, compliance, migration)

Project
ERPFlow
Module
Accounting Module
Type
Test (`test`)
Title
Capability UAT script, দল গ (posting rules, integration, consolidation, compliance, migration)
Branch Name
`feature/accounting-uat-group-c`
View Order
97
Description
**Summary**
দল গ: posting rule engine, source integration (Billing, Procurement, Payroll, Inventory, Project, Commissioning, Asset event), consolidation, auditor access, audit chain, import, archive, API ও webhook — scripted scenario ও চালানো। প্রমাণ: কোনো source event সরাসরি ledger-এ লেখে না; Draft → approval → Post পথে যায়।

**Task serial**
`ACC-P17-04 — Capability UAT script, দল গ (posting rules, integration, consolidation, compliance, migration)` · Test · Phase 17, চতুর্থ card

**Depends on**
- `ACC-P17-01`
- সব P14, P15, P16 card (posting rules ও source integrations; multi-entity/intercompany/consolidation; compliance, audit, data lifecycle, migration ও API; সবই অন্য tab-এ)

**Relation: আগের task**
- `P17-01` দিয়েছে পরিবেশ, ছাঁচ, persona (auditor ও API client role সহ)।
- Phase 4-এর Finance Event Inbox (`P4-02`), consumer job (`P4-03`), Event থেকে Draft Journal (`P4-06`), RC8 (`P4-10`) এই document-এ আছে: Asset event-এর পথ। Phase 14 এই কাঠামো বাকি source-এ বাড়ায় (অন্য tab)।
- Phase 14, 15, 16: অন্য tab-এ; এদের সংজ্ঞা এই document-এ নেই।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-05` (E2E): E1 (Project event) ও E2 (Payroll event) ও E3 (Asset event) পথের সুস্থ উৎস।
- `P17-07` (data migration মহড়া): source এই card-কে নির্ভরতা রেখেছে; Phase 16 import UAT এখানে।
- `P17-06` (negative: malformed webhook ও API token) ও `P17-15` (অন্য tab-এ)।

**Related tables / schema**
নতুন table নেই। পড়া: `acc_finance_event_inbox`, `acc_finance_event_journal_links`, `acc_journals`, `acc_journal_lines`। RC চালানো: RC15, RC18 (Phase 14-16-এর check; সংজ্ঞা এই document-এ নেই)।

**Business rules**
- R17.2, R17.4, R17.6 (event replay-এ নতুন journal নয়, শুধু লিংক পুনরুদ্ধার)।
- প্রতিটা source module থেকে নমুনা event inbox-এ আসে, Draft journal তৈরি হয়, মানুষ approve করে, post হয়।
- Event ফেরত চালানো (replay) স্বাভাবিক সংখ্যায় একই ফল দেয় কিনা দেখা (idempotency)।
- কোনো source event সরাসরি ledger-এ লেখে না (G9 ধরে)।
- প্রতিটা source module-এর অন্তত একটা সুস্থ ও একটা ভুল event।
- Negative case error prefix: RUL_, EVC_, GRP_, ICO_, CON_, AUD_, IMP_, ARC_, API_।
- **Open point:** UAT-14.x থেকে UAT-16.x scenario তালিকা Blueprint-এ, এই document-এ নেই।
- **Open point:** "G9" কী (সম্ভবত Phase 9 বা একটা golden/invariant) source-এ সংজ্ঞা নেই; "OD-105b" কেন এখানে (volume) লিখিত নেই।
- **Open point:** Source module-গুলোর মধ্যে এই document-এ শুধু Asset event reader (`P4-04`) আছে; Billing, Procurement, Payroll, Inventory, Project, Commissioning-এর event কাঠামো Phase 14-এ (অন্য tab), তাই scenario-র input ছাঁচ অজানা।

**DB flow**
- পড়া: `acc_finance_event_inbox`, `acc_finance_event_journal_links`, `acc_journals`, `acc_journal_lines`।
- প্রতিটা source module থেকে নমুনা event inbox-এ আসে, Draft journal তৈরি হয়, মানুষ approve করে, post হয়।
- Event ফেরত চালানো (replay) স্বাভাবিক সংখ্যায় একই ফল দেয় কিনা দেখা (idempotency)।
- RC15, RC18 চালানো।

**Task scope**
1. Phase 14 scenario, প্রতি source আলাদা (Billing, Procurement, Payroll, Inventory, Project, Commissioning, Asset event)।
2. Phase 15 scenario (consolidation, intercompany, elimination)।
3. Phase 16 scenario (auditor access, audit chain, import, archive, API ও webhook)।
4. Defect triage ও পুনরায় চালানো।

**Out of scope**
দল ক ও খ। E2E (`P17-05`)। Data migration মহড়া বাস্তব volume-এ (`P17-07`)। Pen test (`P17-11` ইত্যাদি, অন্য tab)।

**Contract (API)**
Blueprint ২৭.৯ক-এর UAT-14.x থেকে UAT-16.x।

**Permission**
Persona role, সাথে auditor ও API client role।

**Error**
`RUL_`, `EVC_`, `GRP_`, `ICO_`, `CON_`, `AUD_`, `IMP_`, `ARC_`, `API_` প্রত্যাশিত negative case-এ।

**Audit**
`accounting.release.uat_scenario_result`

**Acceptance**
AC17.3: সব scenario pass বা অনুমোদিত exception। কোনো source event সরাসরি ledger-এ লেখে না (G9 ধরে)।

**Test**
নিজেই test। প্রতিটা source module-এর অন্তত একটা সুস্থ ও একটা ভুল event।

**Deliverable**
ফল, defect তালিকা, tech lead ও accountant-এর সই

**Sub-tasks**
1) Phase 14 scenario, প্রতি source আলাদা। 2) Phase 15 scenario। 3) Phase 16 scenario। 4) Defect triage ও পুনরায় চালানো

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.3 সবুজ; কোনো source event সরাসরি ledger-এ লেখে না প্রমাণিত।
- Replay-এ নতুন journal নয় প্রমাণিত।
- Tech lead ও accountant-এর সই।

**Architecture constraints**
- Event কখনো ledger-এ সরাসরি লেখে না; সবসময় Draft → approval → Post।
- Replay শুধু লিংক পুনরুদ্ধার করে, নতুন journal বানায় না।
- ledger হাতে ঠিক করা নিষেধ।

Owner
Dev C
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-05 — Cross-module end-to-end scenario ও golden test

Project
ERPFlow
Module
Accounting Module
Type
Test (`test`)
Title
Cross-module end-to-end scenario ও golden test
Branch Name
`feature/accounting-uat-cross-module-e2e`
View Order
98
Description
**Summary**
চারটা cross-module পথ (E1–E4) শুরু থেকে শেষ — প্রতি ধাপে ledger ও RC যাচাই। এক capability আলাদায় ঠিক থাকলেও জোড়ায় কোথায় ভাঙছে, E2E-তে ধরা পড়বে।

**Task serial**
`ACC-P17-05 — Cross-module end-to-end scenario ও golden test` · Test · Phase 17, পঞ্চম card

**Depends on**
- `ACC-P17-02`
- `ACC-P17-03`
- `ACC-P17-04`

**Relation: আগের task**
- `P17-02` (দল ক): journal, FX, tax, subledger, bank-এর আলাদা প্রমাণ; E1 এর open item ও bank match, tax return, E4 এর foreign currency ও revaluation এর ভিত্তি।
- `P17-03` (দল খ): fixed asset, period-end, year-end ও reporting-এর আলাদা প্রমাণ; E1 (period close, year-end), E3 (capitalization, depreciation, disposal)।
- `P17-04` (দল গ): posting rules ও source integration, consolidation; E1 (Project event, consolidation journal), E2 (Payroll event), E3 (Asset event)।
- এই তিন card পাস না হলে E2E-র ব্যর্থতা কোন capability-র তা আলাদা করা যায় না।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-07` (data migration মহড়া), `P17-08` (parallel run), `P17-15` (অন্য tab-এ): source এই card-কে এদের "অবরুদ্ধ করে"-তে রেখেছে। বাস্তবে `P17-08` ও `P17-09` এই card-কে নির্ভরতা বলেছে; `P17-07` বলেনি (phase-স্তরের open point)।
- `P17-09` (scale ও performance): E2E পাস হওয়া কাঠামোর ওপর load।

**Related tables / schema**
নতুন table নেই। পথ জুড়ে ব্যবহৃত: `acc_finance_event_inbox`, `acc_journals`, `acc_journal_lines`, open item (`acc_` receivable table, নাম Phase 9-এ), bank statement line match ও reconciliation (Phase 10), tax return (Phase 8), `acc_periods`, `acc_period_events`, year-end ও consolidation journal। RC1 থেকে RC18-এর প্রযোজ্যগুলো।

**Business rules**
- R17.2, R17.4, R17.7 (E2E-তে পরের ধাপ আগের ধাপের posted ফলের উপর, কখনো test data হাতে বসিয়ে নয়)।
- প্রতি ধাপের পর RC1 থেকে RC18-এর প্রযোজ্যগুলো চলে।
- প্রতিটা পথ একটা snapshot থেকে শুরু; ব্যর্থ হলে ওই ধাপ থেকে আবার নয়, snapshot থেকে শুরু।
- সব persona আলাদা login; এক ব্যবহারকারী পুরো পথ নয় (SoD সত্যিকারের মতো)।
- E1 পথের হাতে চালানো UAT-ও (accountant দেখে)।
- **চার পথ:**
  - **E1:** Project event → `acc_finance_event_inbox` → Draft journal → post → open item (`acc_` receivable) → bank statement line match → bank reconciliation → tax return → period close (`acc_periods`, `acc_period_events`) → year-end journal → consolidation journal।
  - **E2:** Payroll event → payable → bank payment → bank match।
  - **E3:** Asset acquisition event → capitalization → প্রতি মাসে depreciation run → disposal।
  - **E4:** বিদেশি currency invoice → revaluation journal → settlement → realized gain।
- **Open point:** UAT-E1 থেকে E4 ও G17.1 থেকে G17.4-এর সংখ্যা-সহ expected result Blueprint ২৭.৯গ ও ২৭.৯ঙ-এ; এই document-এ নেই। OD-105b (data volume) সিদ্ধান্ত লিখিত নেই।
- **Open point:** E1 একই পথে এত ধাপ (Phase 4, 8, 9, 10, 12, 15) জুড়ে হওয়ায়, কোনো একটা Phase-এর feature flag বন্ধ থাকলে পথ কীভাবে চলবে, এবং সব flag চালু অবস্থার রাখা পরিবেশে কীভাবে আনা হবে source-এ নেই।

**DB flow**
- **পথ E1:** Project event → `acc_finance_event_inbox` → Draft journal → post → open item (`acc_` receivable) → bank statement line match → bank reconciliation → tax return → period close (`acc_periods`, `acc_period_events`) → year-end journal → consolidation journal।
- **পথ E2:** Payroll event → payable → bank payment → bank match।
- **পথ E3:** Asset acquisition event → capitalization → প্রতি মাসে depreciation run → disposal।
- **পথ E4:** বিদেশি currency invoice → revaluation journal → settlement → realized gain।
- প্রতি ধাপের পর RC1 থেকে RC18-এর প্রযোজ্যগুলো চলে। প্রতিটা পথ একটা snapshot থেকে শুরু; ব্যর্থ হলে ওই ধাপ থেকে আবার নয়, snapshot থেকে শুরু।

**Task scope**
1. E1 পথ।
2. E2 পথ।
3. E3 পথ।
4. E4 পথ।
5. Golden test স্বয়ংক্রিয় করা (G17.1 থেকে G17.4, MySQL-এ)।
6. প্রতি ধাপের RC প্রমাণ।

**Out of scope**
আলাদা capability UAT (`P17-02` থেকে `P17-04`)। Negative/security (`P17-06`)। Volume/performance (`P17-09`)।

**Contract (API)**
Blueprint ২৭.৯গ-এর UAT-E1 থেকে E4 ও ২৭.৯ঙ-এর G17.1 থেকে G17.4। প্রতিটার সংখ্যা সহ expected result সেখানে।

**Permission**
সব persona আলাদা login, এক ব্যবহারকারী পুরো পথ নয় (SoD সত্যিকারের মতো)।

**Error**
কোনোটি নতুন নয়। যেখানে ব্যর্থ, সেই capability-র prefix।

**Audit**
`accounting.release.uat_scenario_result`

**Acceptance**
AC17.4: চার পথ pass। AC17.5: প্রতি ধাপে debit = credit, শেষে RC1 থেকে RC18 সবুজ।

**Test**
G17.1, G17.2, G17.3, G17.4 স্বয়ংক্রিয় ও MySQL-এ। E1 হাতে চালানো UAT-ও (accountant দেখে)।

**Deliverable**
চার পথের ফল প্রতিবেদন, প্রতি ধাপের ledger screenshot বা export, accountant ও finance owner-এর সই

**Sub-tasks**
1) E1 পথ। 2) E2 পথ। 3) E3 পথ। 4) E4 পথ। 5) Golden test স্বয়ংক্রিয় করা। 6) প্রতি ধাপের RC প্রমাণ

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.4, AC17.5 সবুজ; G17.1 থেকে G17.4 MySQL-এ স্বয়ংক্রিয় সবুজ।
- E1 হাতে চালানো UAT accountant দেখেছে।
- Accountant ও finance owner-এর সই।

**Architecture constraints**
- পরের ধাপ সবসময় আগের ধাপের posted ফলের ওপর; test data হাতে বসানো নিষেধ।
- ব্যর্থ হলে ধাপ নয়, snapshot থেকে পুরো পথ আবার।
- SoD সত্যিকারের: আলাদা ব্যবহারকারী।

Owner
Dev A
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-06 — Negative, security ও isolation scenario

Project
ERPFlow
Module
Accounting Module
Type
Test (`test`)
Title
Negative, security ও isolation scenario
Branch Name
`feature/accounting-uat-negative-security-isolation`
View Order
99
Description
**Summary**
Negative ও security: ভুল input বা অনুমতি ছাড়া চেষ্টায় ledger অপরিবর্তিত, error `{code, message, field, details, correlation_id}` ঠিক মতো (stack trace বা অন্য company-র তথ্য নয়), company isolation — এক company-র token দিয়ে অন্যের id 404।

**Task serial**
`ACC-P17-06 — Negative, security ও isolation scenario` · Test · Phase 17, ষষ্ঠ card

**Depends on**
- `ACC-P17-02`
- `ACC-P17-03`
- `ACC-P17-04`

**Relation: আগের task**
- `P17-02`, `P17-03`, `P17-04` পাস হয়ে প্রতিটা capability-র সুস্থ পথ প্রমাণিত; এই card তাদের ভুল পথ পরীক্ষা করে।
- Phase 1-এর `P1-12` (tenancy, audit, error-এর সাধারণ ব্যবস্থা) ও composite FK নিয়ম (AC1.1) এবং `P2-10` SoD service, `P2-12` posting service: এগুলোর বাধা এখানে সরাসরি পরীক্ষিত হয়।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-11` (অন্য tab-এ, এই document-এ নেই) ও `P17-15` (অন্য tab-এ): source এদের এই card-এর ওপর নির্ভরশীল বলেছে।
- এই card-এর "security সই" পরের release-control gate-এ প্রমাণ হিসেবে যায়।

**Related tables / schema**
নতুন table নেই। পড়া: `activity_logs`, `acc_journals` (গণনা আগে ও পরে), `acc_idempotency_keys`।

**Business rules**
- R17.8 (negative scenario-র পাস মানে ফল অপরিবর্তিত ও error আকার সঠিক), R17.9 (বিষয়বস্তু source-এ লেখা নেই)।
- প্রতিটা negative scenario-তে প্রত্যাশা: ledger-এ কোনো বদল নেই; `acc_idempotency_keys`-এ প্রবেশ বা না-প্রবেশ নিয়ম মতো; audit-এ ব্যর্থ চেষ্টার রেকর্ড।
- **Isolation:** দুই company-তে একই code ও id; এক company-র token দিয়ে অন্যের id ডাকলে 404।
- Error আকার `{code, message, field, details, correlation_id}`; কখনো stack trace বা অন্য company-র তথ্য নয়।
- অনুমতিহীন persona ইচ্ছা করে বানানো হয়।
- সবগুলো Cycle 3-এ হাতে ও স্বয়ংক্রিয়ে।
- **Open point:** UAT-N1 থেকে N14 তালিকা Blueprint ২৭.৯ঘ-এ, এই document-এ নেই। OD-107 লিখিত নেই (সম্ভবত security/penetration সংক্রান্ত)।
- **Open point:** R17.9 কী বলে অজানা; "Cycle 3" মানে P17-01 cycle calendar-এর তৃতীয় cycle কিনা নিশ্চিত নয়।
- **Open point:** 404 বনাম `ACC_COMPANY_FORBIDDEN` (403): §২.৩ তালিকায় `ACC_COMPANY_FORBIDDEN` আছে, অথচ এই card isolation-এ 404 চায় (অন্য company-র id অনুমান করলে 404, `P6`-এর IDOR নীতি অনুযায়ী)। কোন পথে কোন কোড আসবে তা মেলাতে হবে।

**DB flow**
- প্রতিটা negative scenario-তে প্রত্যাশা: ledger-এ কোনো বদল নেই; `acc_idempotency_keys`-এ প্রবেশ বা না-প্রবেশ নিয়ম মতো; audit-এ ব্যর্থ চেষ্টার রেকর্ড।
- Isolation: দুই company-তে একই code ও id; এক company-র token দিয়ে অন্যের id ডাকলে 404।
- পড়া: `activity_logs`, `acc_journals` গণনা আগে ও পরে।

**Task scope**
1. অনুমতি ও SoD।
2. Company isolation।
3. Duplicate, locked period, ভুল mapping।
4. Malformed webhook ও API token।
5. Audit chain ছেঁড়া।
6. ব্যর্থ posting ও retry।

**Out of scope**
Penetration test (`PT-n`, `P17-11` ইত্যাদি অন্য tab)। সুস্থ পথের UAT। Accessibility।

**Contract (API)**
Blueprint ২৭.৯ঘ-এর UAT-N1 থেকে N14।

**Permission**
অনুমতিহীন persona বানানো হয় ইচ্ছা করে।

**Error**
প্রত্যাশিত `AccountingError` আকার `{code, message, field, details, correlation_id}`, আর কখনো stack trace বা অন্য company-র তথ্য নয়।

**Audit**
`accounting.release.uat_scenario_result`, আর প্রত্যাখ্যাত চেষ্টার নিজস্ব audit।

**Acceptance**
AC17.6: সব negative pass। AC17.7: company isolation scenario শূন্য ফাঁস।

**Test**
`ReleaseNegativeTest`, `CompanyIsolationTest` (MySQL)। সবগুলো Cycle 3-এ হাতে ও স্বয়ংক্রিয়ে।

**Deliverable**
ফল, ব্যর্থ চেষ্টার log নমুনা, security সই

**Sub-tasks**
1) অনুমতি ও SoD। 2) Company isolation। 3) Duplicate, locked period, ভুল mapping। 4) Malformed webhook ও API token। 5) Audit chain ছেঁড়া। 6) ব্যর্থ posting ও retry

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.6, AC17.7 সবুজ; `ReleaseNegativeTest` ও `CompanyIsolationTest` MySQL-এ সবুজ।
- প্রতিটা negative-এ ledger গণনা অপরিবর্তিত ও error আকার সঠিক।
- Security সই জমা।

**Architecture constraints**
- Negative পাস মানে কেবল error নয়: ফল অপরিবর্তিত থাকা ও audit রেকর্ড থাকা।
- Error কখনো stack trace বা অন্য company-র তথ্য দেখায় না।
- অনুমতিহীন persona ইচ্ছা করে বানানো, scenario permission বাদ দিতে পারে না।

Owner
Dev B
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-07 — Data migration মহড়া, বাস্তব volume-এ

Project
ERPFlow
Module
Accounting Module
Type
Operations + Test (`ops` + `test`)
Title
Data migration মহড়া, বাস্তব volume-এ
Branch Name
`feature/accounting-uat-migration-rehearsal`
View Order
100
Description
**Summary**
Migration মহড়া: প্রতি company-র বাস্তব data দিয়ে import তিনবার (dry-run, copy+মিল, সময়+rollback) — সময়, control total, ত্রুটির হার মাপা। production cutover-এ surprise নেই; শেষ মহড়ার সময় cutover জানালার ভেতরে।

**Task serial**
`ACC-P17-07 — Data migration মহড়া, বাস্তব volume-এ` · Ops + Test · Phase 17, সপ্তম card

**Depends on**
- `ACC-P17-04`
- সব P16 import card (Phase 16: Migration ও import, অন্য tab-এ)
- `ACC-P5-02` (Cutover মহড়া)

**Relation: আগের task**
- `P17-04` (দল গ) Phase 16-এর import ও migration UAT প্রমাণ করেছে; এই card বাস্তব volume-এ সেটাকে সময় মেপে চালায়।
- Phase 16 `ImportService` (dry-run, copy) ও master data mirror: মহড়ার যন্ত্র।
- `P5-02` দিয়েছে cutover মহড়ার পদ্ধতি (ধাপ ১ থেকে ৭, বারবার চালানো, সময় মাপা, trial balance তুলনা); এই card সেটাই enterprise volume ও Phase 16 import দিয়ে বাড়ায়।
- `P2-14` (Opening journal-এর Post) ও `PostingService` (`P2-12`): copy ধাপে opening journal এই পথে।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-08` (parallel run): migration-এ মেলানো opening balance ছাড়া parallel run শুরু হয় না।
- `P17-09` (scale ও performance): source এই card-কে নির্ভরতায় রেখেছে (volume ও পরিবেশ)।
- `P17-15`, `P17-16` (অন্য tab-এ): production cutover-এর প্রস্তুতি।

**Related tables / schema**
নতুন table নেই। মহড়ার পরিবেশে Phase 16 `ImportService` (opening journal ও master data mirror লেখে, `PostingService` দিয়ে)। RC1 থেকে RC18-এর প্রযোজ্যগুলো, legacy trial balance-এর সাথে মিল।

**Business rules**
- R17.1, R17.3, R17.14 (production-এ migration rollback নেই, শুধু মহড়ায় restore)।
- মহড়া তিনবার: dry-run, copy ও মিল, সময়-মাপা ও rollback।
- Dry-run দুইবার একই ফল (idempotency); copy দুইবার নতুন journal বানায় না।
- Rollback মহড়া = snapshot restore। Restore-এর পর RC সবুজ।
- সময়, মেমরি, lock অপেক্ষা মাপা।
- ব্যর্থ হলে snapshot restore ও সমস্যার বিবরণ সহ আবার।
- Legacy trial balance = নতুন opening trial balance (control total শূন্য পার্থক্য)।
- **Open point:** MIG-1 থেকে MIG-6 তালিকা Blueprint ২৭.৯চ-এ, এই document-এ নেই। OD-105b (volume) ও OD-119 লিখিত নেই; "cutover জানালা" (বরাদ্দ সময়) ও "ত্রুটির হারের লিখিত সীমা"র সংখ্যা source-এ নেই।
- **Open point:** `P17-05` এই card-কে "অবরুদ্ধ করে" বলেছে, কিন্তু এই card-এর নির্ভরতায় `P17-05` নেই।
- **Open point:** Phase 5 `P5-02` Opening Balance গ্রিড হাতে ঢোকানোর পদ্ধতি; এখানে Phase 16 import দিয়ে — দুই পদ্ধতির সম্পর্ক (কোনটা production পথ) source-এ বলা নেই।

**DB flow**
মহড়ার পরিবেশে:
1. Snapshot।
2. Phase 16 `ImportService` দিয়ে dry-run (কিছু লেখে না, শুধু ত্রুটি দেখায়)।
3. Copy (opening journal ও master data mirror লেখে, `PostingService` দিয়ে)।
4. তারপর RC1 থেকে RC18-এর প্রযোজ্যগুলো ও legacy trial balance-এর সাথে মিল।
5. Rollback মহড়া = snapshot restore।
6. সময়, মেমরি, lock অপেক্ষা মাপা।

ব্যর্থ হলে snapshot restore, আর সমস্যার বিবরণ সহ আবার।

**Task scope**
1. Volume নিশ্চিত (OD-105b)।
2. মহড়া 1: dry-run।
3. মহড়া 2: copy ও মিল।
4. মহড়া 3: সময়-মাপা ও rollback।
5. Opening balance মিল।
6. Cutover ঘড়ি ও runbook।

**Out of scope**
আসল production cutover। Parallel run (`P17-08`)। Import কোডের পরিবর্তন (Phase 16)।

**Contract (API)**
MIG-1 থেকে MIG-6 (Blueprint ২৭.৯চ)।

**Permission**
`accounting.import.manage` (Phase 16), `accounting.release.manage`

**Error**
`IMP_` (Phase 16), `REL_PRECONDITION_FAILED`

**Audit**
`accounting.release.migration_rehearsal_done`

**Acceptance**
AC17.8: তিনবারের শেষবার সময় বরাদ্দ cutover জানালার ভেতরে। Legacy trial balance = নতুন opening trial balance (control total শূন্য পার্থক্য)। ত্রুটির হার লিখিত সীমার ভেতরে।

**Test**
Dry-run দুইবার একই ফল (idempotency)। Copy দুইবার নতুন journal বানায় না। Restore-এর পর সবুজ RC।

**Deliverable**
প্রতি company-র মহড়া প্রতিবেদন (সময়, volume, ত্রুটি, মিল), cutover ঘড়ি, cutover runbook

**Sub-tasks**
1) Volume নিশ্চিত (OD-105b)। 2) মহড়া 1 dry-run। 3) মহড়া 2 copy ও মিল। 4) মহড়া 3 সময়-মাপা ও rollback। 5) Opening balance মিল। 6) Cutover ঘড়ি ও runbook

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.8 সবুজ: তৃতীয় মহড়ার সময় জানালার ভেতরে; control total শূন্য পার্থক্য; ত্রুটির হার সীমার ভেতরে।
- Dry-run ও copy idempotent প্রমাণিত।
- প্রতি company-র মহড়া প্রতিবেদন ও cutover runbook জমা।

**Architecture constraints**
- Production-এ migration rollback নেই; rollback শুধু মহড়ায় snapshot restore।
- Copy `PostingService` ছাড়া ledger-এ লেখে না।
- Import dry-run কিছু লেখে না।

Owner
Dev A
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-08 — Parallel run ও তুলনা

Project
ERPFlow
Module
Accounting Module
Type
Operations + API (`ops` + `api`)
Title
Parallel run ও তুলনা
Branch Name
`feature/accounting-uat-parallel-run`
View Order
101
Description
**Summary**
Parallel run: নির্ধারিত period জুড়ে পুরোনো ও নতুন পদ্ধতি একসাথে; প্রতিদিন ও period-end-এ trial balance, aging, bank, tax, depreciation মিল। অব্যাখ্যাত discrepancy শূন্য (accepted exception-এ finance owner-এর সই) হলেই পুরোনো পদ্ধতি বন্ধ।

**Task serial**
`ACC-P17-08 — Parallel run ও তুলনা` · Ops + API · Phase 17, অষ্টম card

**Depends on**
- `ACC-P17-05` (cross-module E2E)
- `ACC-P17-07` (migration মহড়া: opening balance মিলে গেছে)

**Relation: আগের task**
- `P17-05` প্রমাণ করেছে চার পথে নতুন system ভেতরে সঙ্গতিপূর্ণ।
- `P17-07` দিয়েছে মিলে যাওয়া opening balance ও Phase 16 import mapping (legacy account code → নতুন account); parallel run-এর legacy ফাইল সেই mapping ব্যবহার করে।
- `P3-04` (Trial Balance), `P3-02` (`acc_period_balances`), `P3-10` (`acc_report_exports`), `P5-06` (`acc_enablement_log`): তুলনার ইনপুট ও আউটপুট table।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-15` (অন্য tab-এ, এই document-এ নেই): parallel run exit সই পরের release-control gate-এর প্রমাণ।
- Parallel run-এর exit শর্ত (`REL_PARALLEL_RUN_OPEN` না থাকা) পুরোনো পদ্ধতি বন্ধের সিদ্ধান্তের শর্ত।

**Related tables / schema**
নতুন table নেই।
- পড়া: `acc_period_balances`, `acc_journals`, `acc_journal_lines` (নতুন পক্ষ)।
- Legacy পক্ষ ফাইলে আসে (account code, debit, credit), Phase 16 import mapping-এ নতুন account-এ ম্যাপ।
- লেখা: কেবল `acc_report_exports`-এ তুলনা report (প্রতি account: legacy, নতুন, পার্থক্য, অবস্থা) ও `acc_enablement_log`-এ এন্ট্রি। Ledger-এ কোনো লেখা নেই।

**Business rules**
- R17.10, R17.11 (বিষয়বস্তু source-এ লেখা নেই)।
- তুলনা idempotent (period key + দিন): ব্যর্থ হলে ওই দিনের তুলনা আবার চালানো যায়।
- **Discrepancy শ্রেণি:** timing, rounding, mapping, rule পার্থক্য, legacy ভুল, নতুন system defect।
- **অবস্থা:** `open`, `explained`, `corrected`, `accepted` (অনুমোদন সহ)।
- Period-end তুলনায় trial balance, aging, bank, tax, depreciation।
- Accepted exception-এ finance owner-এর সই।
- Tolerance সীমায় ও সীমার বাইরে দুই মান পরীক্ষিত।
- ledger-এ কোনো লেখা নেই।
- **Open point:** OD-105 (parallel run-এর period সংখ্যা), OD-105a (script বা API), OD-108b লিখিত নেই; tolerance (rounding/timing সহনীয় পার্থক্য)-এর সংখ্যা source-এ নেই।
- **Open point:** `acc_enablement_log`-এর `flag` মান (P5-06: `accounting.enabled`, `event_intake.*`, `gate:*`) তে parallel run এন্ট্রির জন্য নতুন মান লাগবে (যেমন `gate:parallel_run`); source নির্দিষ্ট করেনি এবং `action` মান (`on`, `off`, `gate_passed`, `gate_revoked`) এর কোনটা ব্যবহৃত হবে তাও।
- **Open point:** `acc_report_exports.format` `xlsx`/`pdf` (P3-10); তুলনা report কোন `report` নাম ও format-এ সংরক্ষিত হবে source-এ নেই।
- **Open point:** Type `api` (OD-105a: script বা API) — endpoint-টি Contract-এ দেওয়া; কিন্তু "script" বেছে নিলে endpoint বাদ যাবে কি না OD-105a-এর ওপর।

**DB flow**
- পড়া: `acc_period_balances`, `acc_journals`, `acc_journal_lines` (নতুন পক্ষ)।
- Legacy পক্ষ ফাইলে আসে (account code, debit, credit), Phase 16 import mapping-এ নতুন account-এ ম্যাপ।
- লেখা: কেবল `acc_report_exports`-এ তুলনা report (প্রতি account: legacy, নতুন, পার্থক্য, অবস্থা) ও `acc_enablement_log`-এ এন্ট্রি।
- Ledger-এ কোনো লেখা নেই।
- ব্যর্থ হলে ওই দিনের তুলনা আবার চালানো যায় (idempotent, period key + দিন)।

**Task scope**
1. Legacy ফাইল ছাঁচ ও mapping।
2. দৈনিক তুলনা।
3. Period-end তুলনা (trial balance, aging, bank, tax, depreciation)।
4. Discrepancy workflow (শ্রেণি, অবস্থা, approval)।
5. Exit criteria পরীক্ষা।

**Out of scope**
Migration মহড়া (`P17-07`)। পুরোনো পদ্ধতি বন্ধের সিদ্ধান্ত (`P17-15`-ধরনের release-control card, অন্য tab)। Ledger সংশোধন।

**Contract (API)**
- `POST /accounting/release/parallel-runs/{period_key}/compare` (দৈনিক ও period-end)।
- Discrepancy শ্রেণি: timing, rounding, mapping, rule পার্থক্য, legacy ভুল, নতুন system defect।
- অবস্থা: open, explained, corrected, accepted (অনুমোদন সহ)।

**Permission**
`accounting.release.manage` (চালানো), `accounting.release.approve` (accepted অবস্থা)

**Error**
`REL_PARALLEL_RUN_OPEN` (exit শর্ত অপূর্ণ)

**Audit**
`accounting.release.parallel_run_compared`, `accounting.release.discrepancy_resolved`

**Acceptance**
AC17.9: সব period-এ অব্যাখ্যাত discrepancy শূন্য, control total পার্থক্য শূন্য, প্রতি accepted exception-এ finance owner-এর সই।

**Test**
বানানো ভুল (mapping, সময়, rounding) ঢোকালে তুলনা সঠিক শ্রেণিতে ধরে কিনা। Tolerance সীমায় ও সীমার বাইরে দুই মান।

**Deliverable**
তুলনা report, discrepancy log, সমাধানের সারাংশ, exit সই

**Sub-tasks**
1) Legacy ফাইল ছাঁচ ও mapping। 2) দৈনিক তুলনা। 3) Period-end তুলনা (trial balance, aging, bank, tax, depreciation)। 4) Discrepancy workflow। 5) Exit criteria পরীক্ষা

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.9 সবুজ: অব্যাখ্যাত discrepancy শূন্য, control total শূন্য পার্থক্য, accepted exception-এ সই।
- বানানো ভুল সঠিক শ্রেণিতে ধরা পড়ে প্রমাণিত; তুলনা idempotent।
- Exit সই জমা।

**Architecture constraints**
- Parallel run ledger-এ কিছু লেখে না।
- তুলনা idempotent: একই period key + দিনে আবার চালালে একই ফল।
- `accepted` অবস্থা শুধু `accounting.release.approve`-ধারীর, সই সহ।

Owner
Dev C
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-09 — Scale ও performance test

Project
ERPFlow
Module
Accounting Module
Type
Test + Operations (`test` + `ops`)
Title
Scale ও performance test
Branch Name
`feature/accounting-uat-scale-performance`
View Order
102
Description
**Summary**
Scale/performance (PF-1–PF-8): নির্ধারিত volume-এ p95 লক্ষ্য, deadlock, lock ক্রম, bottleneck — benchmark প্রতিবেদন ও capacity plan। production load আগে জানা যাবে; fix সংশ্লিষ্ট Phase-এর card-এ, expand-only index দিয়ে।

**Task serial**
`ACC-P17-09 — Scale ও performance test` · Test + Ops · Phase 17, নবম card

**Depends on**
- `ACC-P17-05`
- `ACC-P17-07`
- সব P16 partitioning/archive card (Phase 16, অন্য tab-এ)

**Relation: আগের task**
- `P17-05` প্রমাণ করেছে কার্যকারিতা; `P17-07` দিয়েছে বাস্তব volume-এর data ও আমদানির যন্ত্র।
- Phase 16 partitioning/archive: বড় volume সামলানোর কাঠামো।
- Phase 6-এর perf লক্ষ্য: `P6-13` (10M line × 4 dimension, TB by dimension p95 3 সেকেন্ড, GL প্রথম পৃষ্ঠা 1 সেকেন্ড), `P6-10` (500 line × 4 dimension `validateLines` 150ms), `P6-09` (backfill 20,000 line/সেকেন্ড), `P6-07` (৫,০০০ সারি যাচাই ৬০ সেকেন্ড)। এগুলো PF-2/PF-3-এর ভিত্তিসংখ্যা হিসেবে কাজে লাগে (source-এ সরাসরি যুক্ত বলা নেই)।
- `P3-14` (Phase 3 performance), `P5-05` (শেষ security ও performance যাচাই): আগের পরিমাপ।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-10` (failover ও DR drill): source `P17-10` কে এই card-এর ওপর নির্ভরশীল রেখেছে (লোড চলাকালীন failover)।
- `P17-15` (অন্য tab-এ)।

**Related tables / schema**
নতুন table নেই। আলাদা scale পরিবেশে সিনথেটিক data। পড়া ও মাপা: slow query log, `EXPLAIN`, lock wait, deadlock, queue দৈর্ঘ্য।

**Business rules**
- R17.1, R17.16 (sev1 বা sev2 performance defect gate আটকায়)।
- Lock ক্রম বজায় থাকে কিনা দেখা (journal, approval, account, period, voucher counter)।
- ব্যর্থ হলে সংশোধন সম্পর্কিত phase-এর card-এ (expand-only migration দিয়ে index), এই card-এ নয়।
- **পরীক্ষা তালিকা:** PF-1 সমান্তরাল posting, PF-2 report, PF-3 bulk import, PF-4 depreciation ও revaluation, PF-5 consolidation, PF-6 event intake burst, PF-7 8 ঘণ্টা soak (মিশ্র load), PF-8 period close চলাকালীন posting (lock contention)।
- **Open point:** p95 লক্ষ্যের সংখ্যা (PF-1 থেকে PF-8) source-এ নেই (Blueprint-এ); OD-105b (volume), OD-119 লিখিত নেই।
- **Open point:** এই card-এ বর্ণিত lock ক্রম ("journal, approval, account, period, voucher counter") Phase 6-এর চূড়ান্ত ক্রম (journal, approval request, account, period, number series `FOR SHARE`, counter `FOR UPDATE`, শেষে dimension value `FOR SHARE`)-এর চেয়ে ছোট। Phase 6 বাস্তবায়িত হলে "voucher counter" মানে number series counter ও dimension value lock-ও পরীক্ষায় ধরতে হবে।
- **Open point:** PF-7 "সব RC সবুজ" মানে RC1 থেকে RC18, `RC1d/m/n` সহ কি না নিশ্চিত নয়।
- **Open point:** "capacity পরিকল্পনা (কত বাড়লে কী বাড়াতে হবে)" এর ইনপুট (cpu, memory, DB node আকার) source-এ নেই।

**DB flow**
- আলাদা scale পরিবেশে সিনথেটিক data দিয়ে volume বানানো (API দিয়ে বা Phase 16 import দিয়ে)।
- পড়া ও মাপা: slow query log, `EXPLAIN`, lock wait, deadlock, queue দৈর্ঘ্য।
- Lock ক্রম (journal, approval, account, period, voucher counter) বজায় থাকে কিনা দেখা।
- ব্যর্থ হলে সংশোধন সম্পর্কিত phase-এর card-এ (expand-only migration দিয়ে index), এই card-এ নয়।

**Task scope**
1. Volume বানানোর tool।
2. PF-1 (সমান্তরাল posting), PF-2 (report)।
3. PF-3 (bulk import), PF-4 (depreciation ও revaluation), PF-5 (consolidation)।
4. PF-6 (event intake burst), PF-8 (period close চলাকালীন posting)।
5. PF-7 (8 ঘণ্টা soak, মিশ্র load)।
6. Bottleneck ও পুনরায় মাপা।

**Out of scope**
Index বা কোড সংশোধন (সংশ্লিষ্ট Phase-এর card)। DR drill (`P17-10`)। Production capacity ক্রয়।

**Contract (API)**
PF-1 সমান্তরাল posting, PF-2 report, PF-3 bulk import, PF-4 depreciation ও revaluation, PF-5 consolidation, PF-6 event intake burst, PF-7 8 ঘণ্টা soak (মিশ্র load), PF-8 period close চলাকালীন posting (lock contention)।

**Permission**
`accounting.release.manage`

**Error**
কোনোটি নতুন নয়। Timeout হলে বিদ্যমান error।

**Audit**
`accounting.release.scale_test_done`

**Acceptance**
AC17.10: প্রতিটা PF-এ p95 লক্ষ্যের ভেতরে, deadlock শূন্য বা স্বয়ংক্রিয় retry-তে সমাধান, আর PF-7-এ সব RC সবুজ।

**Test**
PF-1 থেকে PF-8। প্রতিটার পর ফল সংখ্যায় লেখা।

**Deliverable**
Benchmark প্রতিবেদন, bottleneck তালিকা, capacity পরিকল্পনা (কত বাড়লে কী বাড়াতে হবে)

**Sub-tasks**
1) Volume বানানোর tool। 2) PF-1, PF-2। 3) PF-3, PF-4, PF-5। 4) PF-6, PF-8। 5) PF-7 soak। 6) Bottleneck ও পুনরায় মাপা

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.10 সবুজ; প্রতিটা PF-এর ফল সংখ্যায় লিখিত।
- Deadlock শূন্য বা স্বয়ংক্রিয় retry-তে সমাধান; PF-7-এ সব RC সবুজ।
- Benchmark প্রতিবেদন ও capacity পরিকল্পনা জমা; কোনো sev1/sev2 performance defect খোলা নেই।

**Architecture constraints**
- সংশোধন কখনো এই card-এ নয়; সংশ্লিষ্ট Phase-এর card-এ, expand-only migration দিয়ে।
- scale পরিবেশ আলাদা; production-এ কোনো লোড নয়।
- Lock ক্রম ভাঙা কোনো কোড গ্রহণযোগ্য নয়।

Owner
Dev A
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P17-10 — Failover ও DR drill

Project
ERPFlow
Module
Accounting Module
Type
Operations + Test (`ops` + `test`)
Title
Failover ও DR drill
Branch Name
`feature/accounting-uat-failover-dr-drill`
View Order
103
Description
**Summary**
Failover/DR drill (DR-1–DR-6): RPO ও RTO মাপ, লোড চলাকালীন primary বন্ধ, restore/failover-র পর journal গণনা ও posted hash, inbox identity — কোনো event হারায় না, duplicate journal হয় না; RC1–RC18 ও audit chain সবুজ।

**Task serial**
`ACC-P17-10 — Failover ও DR drill` · Ops + Test · Phase 17, দশম (এই document-এর শেষ) card

**Depends on**
- `ACC-P17-09`
- সব P16 DR card (Phase 16: backup/restore/DR, অন্য tab-এ)
- `ACC-P5-04` (Rollback ও জরুরি বন্ধ পরিকল্পনা)

**Relation: আগের task**
- `P17-09` দিয়েছে লোড-সক্ষম পরিবেশ ও মিশ্র load (PF-7 soak): DR drill লোড চলাকালীন primary বন্ধ করে।
- Phase 16 DR card: backup, restore, failover কাঠামো ও runbook (অন্য tab-এ)।
- `P5-04` দিয়েছে rollback স্তর (flag বন্ধ, code আগের version-এ, module বন্ধ) ও "করা যাবে না" তালিকা (production-এ trigger-এর `down()` নিষেধ ইত্যাদি) এবং migration সামঞ্জস্য তালিকা; drill এই runbook-এর সংশোধিত রূপ বানায়।
- `P4-02` (Finance Event Inbox, identity-ভিত্তিক idempotency) ও `P4-03` (consumer job): DR-4-এ event হারানো ও দুর্বার journal না হওয়ার ভিত্তি।
- `P3-13` (RC) ও Phase 16 audit chain: drill-এর পরে যাচাই।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P17-15`, `P17-19` (অন্য tab-এ, এই document-এ নেই): source এদের এই card-এর ওপর নির্ভরশীল বলেছে; DR drill সবুজ না হলে release-control gate (go/no-go) পার হয় না।
- সংশোধিত runbook পরের hypercare/rollback card-এর ইনপুট (অন্য tab)।

**Related tables / schema**
নতুন table নেই। পড়া: সব `acc_journals` (গণনা ও posted hash), `acc_finance_event_inbox` ও outbox, `acc_reconciliation_runs` (RC1 থেকে RC18), Phase 16 audit chain।

**Business rules**
- R17.18 (বিষয়বস্তু source-এ লেখা নেই)।
- Drill-এর আগে স্থির অবস্থায় সব `acc_journals` গণনা ও posted hash নেওয়া।
- লোড চলাকালীন primary বন্ধ; Failover অথবা point-in-time restore।
- পরে গণনায় কত গেছে (RPO মাপ) ও কতক্ষণ লাগল (RTO মাপ)।
- `acc_finance_event_inbox` ও outbox কোনো event হারায়নি ও দুর্বার (দুইবার) journal বানায়নি (inbox identity)।
- RC1 থেকে RC18 ও audit chain যাচাই (Phase 16)।
- মানুষ runbook অনুসরণ করে (স্বয়ংক্রিয় script নয়)।
- ব্যর্থ হলে কারণ লিখে আবার drill।
- **Drill তালিকা:** DR-1 DB primary বন্ধ; DR-2 application node বন্ধ; DR-3 backup থেকে point-in-time restore; DR-4 queue ও inbox পুনরুদ্ধার; DR-5 hosting এলাকা হারানো (OD-115 থাকলে); DR-6 drill-এর পর RC ও audit chain।
- RPO ও RTO লক্ষ্য OD-114 নিশ্চিত না হলে প্রস্তাব 15 মিনিট ও 4 ঘণ্টা।
- **Open point:** OD-114 (RPO/RTO) ও OD-115 (hosting এলাকা) লিখিত সিদ্ধান্ত নেই; প্রস্তাবিত 15 মিনিট/4 ঘণ্টা আপাতত ধরা, client সম্মতি লাগবে।
- **Open point:** "কোনো event হারায় নি, কোনো দুর্বার journal নেই" — মূল ঘটনার বিন্যাস "outbox" বলতে কোন outbox (Asset-এর `asset_finance_events` outbox, যা Accounting শুধু পড়ে) তা source-এ সুনির্দিষ্ট নয়।
- **Open point:** "দুর্বার" বানান সম্ভবত "দুবার" (duplicate) অর্থে; ধরা হয়েছে নকল journal।
- **Open point:** `P17-10` কে `P17-09` পাস করতেই হবে (নির্ভরতা), কিন্তু DR drill-এ লোডের মাত্রা ("লোড চলাকালীন") কত হবে source-এ নেই।

**DB flow**
- Drill-এর আগে স্থির অবস্থায় সব `acc_journals` গণনা ও posted hash নেওয়া।
- লোড চলাকালীন primary বন্ধ।
- Failover অথবা point-in-time restore।
- পরে গণনায় কত গেছে (RPO মাপ) ও কতক্ষণ লাগল (RTO মাপ)।
- `acc_finance_event_inbox` ও outbox কোনো event হারায়নি ও দুবার journal বানায়নি (inbox identity)।
- RC1 থেকে RC18 ও audit chain যাচাই (Phase 16)।
- ব্যর্থ হলে কারণ লিখে আবার drill।

**Task scope**
1. Drill পরিকল্পনা ও অনুমতি।
2. DR-1 (DB primary বন্ধ), DR-2 (application node বন্ধ)।
3. DR-3 (point-in-time restore)।
4. DR-4 (queue ও inbox পুনরুদ্ধার)।
5. DR-5 (hosting এলাকা হারানো, যদি প্রযোজ্য)।
6. DR-6 ও প্রতিবেদন।

**Out of scope**
Backup/DR ব্যবস্থার নির্মাণ (Phase 16)। স্বয়ংক্রিয় failover script (drill মানুষ করে)। Go/no-go সিদ্ধান্ত (পরের release-control card, অন্য tab)।

**Contract (API)**
DR-1 DB primary বন্ধ, DR-2 application node বন্ধ, DR-3 backup থেকে point-in-time restore, DR-4 queue ও inbox পুনরুদ্ধার, DR-5 hosting এলাকা হারানো (OD-115 থাকলে), DR-6 drill-এর পর RC ও audit chain।

**Permission**
`accounting.release.manage`, ops role

**Error**
কোনোটি নতুন নয়।

**Audit**
`accounting.release.dr_drill_done`

**Acceptance**
AC17.11: RPO ও RTO লক্ষ্যের ভেতরে (OD-114 নিশ্চিত না হলে প্রস্তাব 15 মিনিট ও 4 ঘণ্টা), কোনো event হারায়নি, কোনো দুবার (নকল) journal নেই, RC সবুজ।

**Test**
DR-1 থেকে DR-6, সময় ঘড়ি ধরে, মানুষ runbook অনুসরণ করে (স্বয়ংক্রিয় script নয়)।

**Deliverable**
Drill প্রতিবেদন (সময়রেখা, মাপা RPO ও RTO), সংশোধিত runbook, পরের drill-এর তারিখ

**Sub-tasks**
1) Drill পরিকল্পনা ও অনুমতি। 2) DR-1, DR-2। 3) DR-3। 4) DR-4। 5) DR-5 (যদি প্রযোজ্য)। 6) DR-6 ও প্রতিবেদন

**Definition of done**
- সাধারণ DoD পূরণ।
- AC17.11 সবুজ: RPO ও RTO লক্ষ্যের ভেতরে, কোনো event হারায়নি, নকল journal নেই, RC1 থেকে RC18 ও audit chain সবুজ।
- Drill মানুষ runbook ধরে করেছে (সময় ঘড়ি ধরে), সংশোধিত runbook ও পরের drill-এর তারিখ জমা।

**Architecture constraints**
- Drill স্বয়ংক্রিয় script নয়; মানুষ runbook অনুসরণ করবে।
- Posted journal হারানো বা নকল তৈরি গ্রহণযোগ্য নয় (inbox identity দিয়ে ঠেকানো)।
- Drill production-এ নয়; আলাদা পরিবেশে।

Owner
Dev B
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment
