fixed_assets oilasi + FA inventar raqami

finalize-ep-12 yangiladi

Yangilandi: pr_url

finalize-ep-12 yangiladi

Yangilandi: branch, commit_sha

pm-agent yangiladi

Yangilandi: estimate_hours

pm-agent yangiladi

Yangilandi: estimate_hours

team-lead-pm yangiladi

Yangilandi: estimate_hours

qa-ep-12-t01 statusni o'zgartirdi Review → Bajarildi

qa-ep-12-t01 statusni o'zgartirdi Ishlanyapti → Review

qa-ep-12-t01 statusni o'zgartirdi Tayyor → Ishlanyapti

qa-ep-12-t01 izoh qoldirdi

QA 2-urinish (izolyatsiyalangan worktree /tmp/qa-ep12-t01-a2, HEAD ba77d76) — QABUL QILINDI. Testlar: 16/16 yashil (FixedAssetsFamilyMigrationTest), 1-urinishdagi 15 ta ustiga yangi DEFAULT testi qo'shilgan. TUZATISH TEKSHIRILDI — V45 dagi o'zgarish aynan 3 qator, boshqa hech narsaga tegilmagan (git diff 2240106..ba77d76 bilan tasdiqlandi), shuning uchun 1-urinishda isbotlangan 4152/4153/4154 kuchda qoladi: - status DEFAULT 'draft' -> 'in_transit' (§2.9d "Default `in_transit`", §4.8 "(yaratish) -> in_transit") - CHECK (status IN ('in_transit', 'received')) — §2.9d/§4.8 dagi eng qisqa ikki holatli mashina; draft/cancelled/rejected/pending_approval endi rad etiladi (ularga §7 va 09_auth §7.2 da rule kodi yo'q) - chk_fixed_asset_transfers_received_status endi EKVIVALENTLIK: (status='received') = (received_at IS NOT NULL) — §2.9d "status='received' bo'lguncha NULL" ikki yo'nalishda ham qotirildi MUTATSIYA (yangi qoplama yolg'onni ushlay oladimi — 4/4 mutant O'LDI, tirigi yo'q): - M9 DEFAULT 'in_transit' -> 'received' => transferDefaultStatusIsInTransitBecauseTheRowIsBornOnDispatch:334 YIQILDI (qo'shimcha dalil: ekvivalentlik CHECK'i ham darhol ishga tushdi — qabul izisiz 'received' qator tug'ilmaydi). - M10 DEFAULT butunlay olib tashlandi => o'sha test:334 YIQILDI (NOT NULL buzilishi). Ya'ni 1-urinishdagi topilma endi haqiqatan qoplangan: default'siz ham, noto'g'ri default bilan ham barg o'tmaydi. - M11 CHECK ro'yxatiga 'draft' qo'shildi => transferStatusIsExactlyInTransitOrReceived:314 YIQILDI. - M12 received_status ekvivalentligi bir tomonlama qilindi (status <> 'received' OR received_at IS NOT NULL) => receiveTraceExistsExactlyWhenStatusIsReceived:367 YIQILDI — ya'ni "in_transit da qabul izi bo'lmaydi" teskari yo'nalishi haqiqatan qo'riqlanadi, formal CHECK emas. Mezonlar 4152/4153/4154 — 1-urinishda M5 (uq_fixed_assets_inventory_number -> org kesimi, test:98), M6 (unikal indeksdan period_year, test:158), M7 (revaluations ga expense_entry_id, test:198) mutantlari bilan isbotlangan; V45 ning o'sha qismlari bu commit'da o'zgarmagan. Ish daraxti toza: git diff HEAD bo'sh, MUTANT/.orig qoldiq yo'q, worktree o'chirildi. Asosiy daraxtga yozilmagan.

qa-ep-12-t01 qabul mezonini belgiladi

✓ `fixed_asset_revaluations` da xarajat FK ustuni yo'qligi tasdiqlangan

qa-ep-12-t01 qabul mezonini belgiladi

✓ Bitta aktivga bir oyda ikkinchi amortizatsiya qatori yozilmaydi

qa-ep-12-t01 qabul mezonini belgiladi

✓ Ikki filialda bir xil `FA10001` yozib bo'lmaydi (butun DB bo'ylab unikal)

worker-ep-12-t01 izoh qoldirdi

TUZATISH (oldingi izohimni bekor qiladi): "erp/docs §2.9d hali eski matnda" degan gapim NOTO'G'RI edi — doc allaqachon yangilangan. §2.9d Q63 = A (2026-09-07) bilan qayta yozilgan va §4.8 holat mashinasi qo'shilgan: status AYNAN in_transit | received, DEFAULT in_transit; draft/cancelled/rejected/pending_approval ATAYLAB yo'q (§7 va 09_auth §7.2 da mos rule kodi ta'riflanmagan). DOC QARZI YO'Q. Migratsiya birinchi urinishda V18 warehouse_transfers ro'yxatini qotirgan edi — QA ushladi, ba77d76 da spec'ga moslashtirildi (DEFAULT endi alohida test bilan qoplangan).

system statusni o'zgartirdi Ishlanyapti → Tayyor

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

system bo'shatdi

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

qa-ep-12-t01 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-12-t01 izoh qoldirdi

QA (izolyatsiyalangan worktree, HEAD 2240106). Testlar: 15/15 yashil (FixedAssetsFamilyMigrationTest). Uchala mezon (4152/4153/4154) BAJARILGAN va mutatsiya bilan isbotlangan — lekin §2.9d bo'yicha bitta spec chetlanishi bor, shuning uchun barg qaytarilyapti. MEZONLAR (mutatsiya bilan isbotlandi, 4/4 mutant o'ldi, tirigi yo'q): - 4152: M5 uq_fixed_assets_inventory_number -> (organization_id, inventory_number) => inventoryNumberIsUniqueAcrossTheWholeDatabaseNotPerOrganization:98 YIQILDI. - 4153: M6 unikal indeksdan period_year olib tashlandi => secondDepreciationForSameAssetAndMonthIsRejected:158 YIQILDI (2027/7 shoxobchasi qo'riqlaydi). - 4154: M7 fixed_asset_revaluations ga expense_entry_id bigint qo'shildi => revaluationsHasNoExpenseForeignKeyColumn:198 YIQILDI. - Qo'shimcha M8: fixed_asset_transfers status CHECK ro'yxatiga 'pending_approval' qo'shildi => transferUsesWarehouseTransferStatusVocabularyAndReceiveLeg:311 YIQILDI. 🔴 QAYTARISH SABABI — 1 ta chetlanish: Fayl: src/main/resources/db/migration/V45__fixed_assets_family.sql:238 status varchar(20) NOT NULL DEFAULT 'draft' Kutilgan: DEFAULT 'in_transit'. Olingan: DEFAULT 'draft'. Asos: 08_finance §2.9d jadvali status qatorida "Default `in_transit`" deb yozilgan, §4.8 holat mashinasi esa yaratishdan to'g'ridan-to'g'ri `in_transit` ga o'tadi ("(yaratish / fixed_asset.transfer) -> in_transit; fixed_assets.organization_id O'ZGARMAYDI"). Ya'ni jo'natish oyog'i yaratilishi bilan aktiv YO'LDA bo'ladi; `draft` — §4.8 da mavjud bo'lmagan holat. Hozirgi default bilan servis qatlami statusni aniq uzatmasa, ko'chirish spec'da yo'q holatda qoladi. Qo'shimcha: bu defaultni HECH BIR test qoplamaydi — testda transfer har doim statusni aniq uzatadi (insertTransfer), shuning uchun xato jim o'tib ketardi. Tuzatish bilan birga default'ni tekshiradigan assert ham kerak (assetDefaultsMatchSpec naqshi). ⚠️ LEAD UCHUN QAROR KERAK (bu coder aybi emas, tuzatish talab qilinmaydi): Brifda "spec §2.9d hali eski matnda" deyilgan edi — bu endi TO'G'RI EMAS: 08_finance §2.9d va §4.8 allaqachon Q63 = A (2026-09-07) bilan yangilangan va ular status ro'yxatini AYNAN `in_transit` | `received` deb belgilaydi, `draft` / `cancelled` / `rejected` / `pending_approval` ni esa ATAYLAB rad etadi (sabab: §7 va 09_auth §7.2 da ularga mos rule kodi yo'q — faqat fixed_asset.transfer va fixed_asset.receive). Migratsiya esa V18 warehouse_transfers ro'yxatini (draft|in_transit|received|cancelled) olgan va test uni qotirib qo'ygan (transferUsesWarehouseTransferStatusVocabularyAndReceiveLeg draft/cancelled QABUL qilinishini talab qiladi). Qaysi biri kuchda — spec matnimi yoki brif ko'rsatmasimi — lead/PM hal qilsin; CHECK ro'yxatining kengligi o'z-o'zicha zarar qilmaydi (servis tor mashinani ishlatadi), lekin DEFAULT masalasi yuqoridagidek har ikki o'qishda ham xato. QOLGAN QISM TOZA (§2.9b–f): depreciation_method va group_id YO'Q (Q29/Q30), fixed_asset_groups jadvali yaratilmagan; revaluations da expense_entry_id YO'Q (Q40 = A); transfers da shipped_* ustunlari YO'Q, received_by_user_id / received_at BOR va juftlik CHECK'i bilan qo'riqlangan; inventory_number char(7) + FA+5 xona sequence; depreciations da expense_entry_id NOT NULL; UNIQUE(asset_id, period_year, period_month). FIXTURE XILMA-XILLIGI — yetarli: oy 0 / 7 / 8 / 12 / 13, yil 2026 / 2027, extra_life_months -1 / 0 / 12, useful_life 0 / 12 / 60, revaluation farqi musbat (+36 000 000) va manfiy (-20 000 000). CROSS-CUTTING: tenant_id yo'q (AR-1) OK; kataloglarga haqiqiy FK (organizations, employees, payments, accounting_periods, expense_entries, users) OK; snake_case + ko'plik + to'liq FK nomi OK; precision 18,2 OK; fizik DELETE yo'q (hamma FK ON DELETE RESTRICT).

qa-ep-12-t01 qabul mezonini belgiladi

✓ `fixed_asset_revaluations` da xarajat FK ustuni yo'qligi tasdiqlangan

qa-ep-12-t01 qabul mezonini belgiladi

✓ Bitta aktivga bir oyda ikkinchi amortizatsiya qatori yozilmaydi

qa-ep-12-t01 qabul mezonini belgiladi

✓ Ikki filialda bir xil `FA10001` yozib bo'lmaydi (butun DB bo'ylab unikal)

worker-ep-12-t01 izoh qoldirdi

fixed_asset_transfers IKKI QADAMLI yozildi (2026-09-07 foydalanuvchi javobi, §5 sikli): status (V18 warehouse_transfers ro'yxati aynan — draft|in_transit|received|cancelled) + received_by_user_id + received_at. shipped_* ustunlari yo'q. DOC QARZI (lead uchun): erp/docs 08_finance §2.9d hali eski matnda — "tasdiq bosqichisiz", ustunlar jadvalida status/received_* yo'q. Doc §5 sikli orqali yangilanishi kerak, aks holda keyingi o'quvchi migratsiyani spec'dan chetga chiqqan deb hisoblaydi. Qabul XATTI-HARAKATI EP-12-T04-S04 da; kontraktda /receive yo'li hozircha yo'q (lead alohida tuzatadi).

worker-ep-12-t01 statusni o'zgartirdi Ishlanyapti → Review

worker-ep-12-t01 fayllarni qayd etdi

2 ta fayl qayd etildi

worker-ep-12-t01 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

worker-ep-12-t01 ishga oldi

team-lead-pm izoh qoldirdi

LEAD IZOHI — fixed_asset_transfers JADVALI 2.9d BO'YICHA AYNAN YOZILSIN. 2.9d jadval spetsifikatsiyasi to'liq: id, asset_id, from_organization_id/to_organization_id, transfer_date, reason, created_by_user_id/created_at. Status ustuni YO'Q, received_by/received_at YO'Q. Shu holicha yoz — qo'shimcha ustun O'YLAB TOPMA. ⚠️ Ochiq savol (bu bargni BLOKLAMAYDI): 2.9d 'tasdiq bosqichisiz' deydi, lekin 09_auth 7.2 da fixed_asset.receive rule'i ATAYLAB bor (Q27 = A, 7.8d: 'qabul = alohida rule' naqshi aktivda tushib qolgan edi) va u kodda seed qilingan. Ikkalasi zid. Savol erp/ 5 sikliga uzatildi. Javob 'ikki qadamli' chiqsa — additive migratsiya bilan ustun qo'shiladi (Flyway append-only, arzon). Xatti-harakat tomoni EP-12-T04-S04 da.

pm-agent yaratdi

fixed_assets oilasi + FA inventar raqami