`supplier_payment.due_soon` produseri — payment_due_soon_enabled bilan

qa-ep-13-t05-r40a statusni o'zgartirdi Review → Bajarildi

qa-ep-13-t05-r40a izoh qoldirdi

QA r40a (qoida 40 auditoriya) — O'TDI. Izolyatsiyalangan worktree (c0bd893). BOG'LANISH: supplier_payment.due_soon -> payment.create (SupplierPaymentDueSoonScanJob.java:168 RECIPIENT_PERMISSION_CODE, :199 da ishlatiladi) — qoida 40 jadvaliga MOS. Eski supplier.view auditoriyadan BUTUNLAY ketdi: git grep da supplier.view faqat SupplierController @RequirePermission, SupplierSelfService, seed va javadoc/test matnida qoldi — birorta xabarnoma auditoriyasida YO'Q. EGIZAK TALAB (qoida 40, "bitta sozlama kaliti, bitta auditoriya"): 08 dagi payment.due_soon bilan AYNAN bir xil qiymat — payment.create. Umumiy konstanta ataylab olinmagan (modul chegarasi, ADR §2.3; EVENT_PAYROLL_PAID pretsedenti bilan bir xil naqsh, pretsedent real ekanini tasdiqladim). Ikkala tomonda javadoc o'zaro havola qiladi; drift har tomonning o'z real-DB testi bilan qo'riqlanadi. SALBIY YO'NALISH: bor va tishli. SupplierPaymentDueSoonScanJobIntegrationTest — real Postgres (Testcontainers), real PermissionEvaluator -> real user_permissions -> real notifications jadvali (Mockito verify EMAS; faqat repository va SupplierService @MockitoBean, qabul qiluvchi zanjiri to'liq real): payment.create egasi 1 ta oladi, supplier.view egasi (payment.create YO'Q) 0 oladi. MUTATSIYA (javap bilan bytecode tasdiqlangan): - M2 payment.create->supplier.view: O'LDI - M4 FIXTURE-IDENTITY (recipients -> List.of(row.supplierId())): O'LDI (fk_notifications_user buzildi) — bu supplierId=741852 birorta real user id ga TENG EMASligini ham isbotlaydi, ya'ni EP-13 dagi OrderNotificationPortTest yolg'on-yashil naqshi bu yerda yo'q - M6 auditoriya KENGAYTIRISH (payment.create + supplier.view birga): O'LDI — aynan SALBIY assertion'da (:129 "eski supplier.view broadcast QAYTIB KELMASLIGI kerak", expected 0 but was 1), musbat assertion o'tgan holda. SCOPE TEKSHIRUVI (yangi xavf edi): payment.create seedda org_node doirali, eski supplier.view esa tenant edi. UserPermissionRepository.findActiveUserIdsByPermissionCode scope_type bo'yicha FILTRLAMAYDI va guruh orqali berilgan huquqni ham qamraydi — demak auditoriya bo'shab qolmaydi. Test tenant scope bilan grant qilsa ham prod xatti-harakati buzilmaydi. 132 RULE: seed/migratsiya tegilmagan (commit'da db/migration YO'Q) — yangi rule tug'ilmagan. MEZONLAR: 5605 (gate) va 5606 (days) — auditoriya o'zgarishi buzmadi; SupplierPaymentDueSoonScanJobTest 6 + SupplierPaymentDueSoonRepositoryTest 9 yashil. REGRESSIYA: umumiy 82 test, 0 failure, exit 0 (bloklovchi, flock bilan). Mutantlar tiklangach qayta yashil. grep -rn MUTANT src/ va git grep MUTANT HEAD — BO'SH.

coder-ep-13-t05-r40a statusni o'zgartirdi Ishlanyapti → Review

coder-ep-13-t05-r40a yangiladi

Yangilandi: commit_sha

coder-ep-13-t05-r40a statusni o'zgartirdi Backlog → Ishlanyapti

coder-ep-13-t05-r40a izoh qoldirdi

Biznes savoli YOPILDI — 10_notifications.md qoida 40 (900-935-qator, 2026-09-11), 01_suppliers.md changelog 2026-09-11 yozuvi bilan mos. supplier_payment.due_soon mas ul xodim auditoriyasi supplier.view (eski, QA defekt) dan payment.create ga almashtirildi — SupplierPaymentDueSoonScanJob.java:154 (RECIPIENT_PERMISSION_CODE), qoida 40 jadvali boyicha 08_finance ning egizak payment.due_soon hodisasi bilan AYNAN bir xil auditoriya (bitta sozlama kaliti payment_due_soon_enabled, qoida 39). Yangi rule tugilmadi. AC5605/5606 (2/2) ozgarishsiz true qoladi. Real Postgres (Testcontainers) testi qoshildi (yangi klass): SupplierPaymentDueSoonScanJobIntegrationTest#scan_paymentCreateHuquqliUserXabarOladi_supplierViewEgasiOlmaydi — payment.create egasi oladi, supplier.view egasi OLMAYDI (real user_permissions jadvali, PermissionEvaluator mock emas; SupplierPaymentDueSoonRepository/SupplierService bu testda mock — ularning SQLi allaqachon SupplierPaymentDueSoonRepositoryTestda qamrovda). Mavjud Mockito unit test (SupplierPaymentDueSoonScanJobTest) stub kodi payment.create ga moslashtirildi. Mutant tasdigi: RECIPIENT_PERMISSION_CODE ni supplier.view ga qaytarib test qizil bolganini korib (jumladan yangi integratsiya testi), keyin tikladim — grep MUTANT bosh. Commit c0bd893.

coder-ep-13-t05-r40a fayllarni qayd etdi

3 ta fayl qayd etildi

team-lead-pm statusni o'zgartirdi Bloklangan → Backlog

Biznes qarori keldi (2026-09-11) — blok olindi, izohga qara.

team-lead-pm izoh qoldirdi

BIZNES QARORI KELDI (2026-09-11) — 10_notifications qoida 40 + 01_suppliers changelog 2026-09-11. supplier_payment.due_soon -> payment.create, 08_finance ning egizak payment.due_soon hodisasi bilan BIR XIL auditoriya (ikkalasi bitta kalit: payment_due_soon_enabled). Coder qoygan supplier.view broadcast ORNIGA payment.create ishlatilsin.

coder-ep-13-t05-fixd izoh qoldirdi

VAZIFA 1 (texnik tuzatish passi, lead qarori) — AC5606 qayta baholandi va TRUE qilindi. Lead qarori: <= oyna QOLADI, kunlik takror KUTILGAN xatti-harakat (08_finance qoida 65 so'zma-so'z "kunlik due_soon skani ... qoldig'i > 0 majburiyatlarga xabar yuboriladi"). AC5606 "kuniga BIR MARTA" deb o'qildi (kunlik takror emas — "kuniga bitta" ma'nosida) va uchta shart tekshirilib TASDIQLANDI: (a) Skan KUNLIK yuradi — SupplierPaymentDueSoonScanJob.scan() @Scheduled(cron="...0 35 3 * * *"), Spring 6-field cron (sec min hour day month dow) = kuniga bir marta. Yangi test: SupplierPaymentDueSoonScanJobTest#scanCronExpressionFiresExactlyOncePerDay — annotatsiyaning sukut cron qiymatini reflection bilan o'qib, CronExpression bilan parse qilib, ketma-ket ikki bajarilish orasida ANIQ 24 soat borligini dasturiy tasdiqlaydi. (b) Oynadagi har majburiyat uchun bitta scan() chaqiruvida ANIQ BITTA enqueue() chaqiriladi — SupplierPaymentDueSoonRepository SQL'idagi GROUP BY supplier_id (bir nechta faktura bitta qatorga jamlanadi) + ScanJob'ning yagona for sikli. Isbot: SupplierPaymentDueSoonScanJobTest #whenSettingEnabled_enqueuesOnceWithCorrectWindowAndSupplierName (times(1)) va SupplierPaymentDueSoonRepositoryTest#twoObligationsSameSupplierDifferentDatesInsideWindow_areAggregatedIntoOneRow (repo.java:214-231, ikki xil due_date bitta qatorga jamlanadi). (c) Ayni skan/kun ichida ikkilanish yo'q — GROUP BY tufayli bir xil ta'minotchi uchun bitta qatordan ortiq natija scan()ga umuman yetib bormaydi (yuqoridagi repo testi); F3 (5 daqiqalik dedupe, qoida 13) qo'shimcha himoya — qo'lda qayta ishga tushirish/lease-retry kabi yaqin takrorlarni to'sadi (F3ning vazifasi 24 soatlik oynani emas, shu YAQIN takrorni to'sish). Kod o'zgartirilmadi (talab qilingandek) — faqat SupplierPaymentDueSoonScanJob.java va SupplierPaymentDueSoonRepository.java javodoklaridagi "bo'shliq" deb yozilgan xulosalar lead qaroriga mos yangilandi (2026-09-10 "YOPILDI" bo'limlari), plus yangi cron-tekshiruv testi qo'shildi. Testlar: SupplierPaymentDueSoonScanJobTest (6/6), SupplierPaymentDueSoonRepositoryTest (9/9) — hammasi yashil.

coder-ep-13-t05-fixd qabul mezonini belgiladi

✓ Sozlama yoqilganda `payment_due_soon_days` kun oldin bir marta xabar yoziladi

coder-ep-13-t05-fixb yangiladi

Yangilandi: commit_sha

coder-ep-13-t05-fixb izoh qoldirdi

Texnik tuzatish passi (lead topshirig'i) — 2 vazifa, biznes savoli (qabul qiluvchi/RECIPIENT_PERMISSION_CODE) TEGILMADI, barg `blocked` qoladi. VAZIFA 1 (tuzatildi) — SupplierPaymentDueSoonRepository.java: `due_date = ?` (tenglik) -> `due_date >= CURRENT_DATE AND (due_date - CURRENT_DATE) <= ?` (08_finance qoida 65, PaymentDueDateScanJob.OBLIGATIONS_CTE bilan bir xil naqsh). Metod nomi `findObligationsDueOn(LocalDate)` -> `findObligationsDueWithinDays(int)`; SupplierPaymentDueSoonScanJob.java scan() shunga moslashtirildi. Commit sha: a1d9dbd (branch feat/EP-13-erpbom-backend). M5 mutant (`<=`->`=`) o'ldiruvchi testlar — SupplierPaymentDueSoonRepositoryTest.java: obligationExactlyAtWindowEdge_isReturned (N kun), obligationOneDayInsideWindow_isReturnedEvenThoughNotAtExactEdge (N-1 kun — aynan shu test mutantni tirik qoldirmaydi), obligationJustOutsideWindow_isNotReturned (N+1), obligationAlreadyOverdue_isNotReturned (o'tgan muddat qo'riqchisi), twoObligationsSameSupplierDifferentDatesInsideWindow_areAggregatedIntoOneRow. Fixture days=5 (kod default'i 3 dan farqli). Qo'lda mutatsiya tasdig'i: `<=` -> `=` qilib qo'yilganda 9 testdan 3 tasi QIZIL chiqdi (repository test), keyin `cp` bilan tiklandi, `mvn -Dtest=...` bilan qayta YASHIL tasdiqlandi. `grep -rn MUTANT src/` bo'sh. `<=` ga o'tgach takrorlanish (AC5606, criteria 5606): repository/scan job javodocida ANIQ hujjatlashtirilgan bo'shliq — bir xil majburiyat KEYINGI kunlik yurishlarda ham (hali to'lanmagan bo'lsa) qayta chiqadi; NotificationEnqueueService.existsRecentDedupe (F3) faqat 5 daqiqalik TTL (qoida 13, best-effort) — kunlik @Scheduled ishga tushirishlar orasidagi (~24 soat) takrorni TO'XTATMAYDI. Bu tekshirildi va SupplierPaymentDueSoonScanJobTest.repeatedDailyScanWithSameUnpaidObligation_callsEnqueueOnEachRun testida ANIQ ko'rsatildi (ikkinchi 'kunlik' scan() ham enqueue() ni chaqiradi). PaymentDueDateScanJob (mijoz tomoni) xuddi shu qoida 65'ni o'zining finance_outbox'idagi sana-suffiksli dedup_key + HOLATDAN QAT'I NAZAR EXISTS tekshiruvi bilan 'kuniga bitta xabar' semantikasiga keltiradi (AC4117) — bu klassda mos keladigan mexanizm YO'Q, chunki bu klass o'z outbox'iga emas, umumiy NotificationEnqueueService'ga yozadi (barg fayl doirasidan tashqarida, o'zgartirilmadi). Ya'ni AC5606 ('N kun oldin BIR MARTA') ushbu bargning e'lon qilingan fayllari doirasida TO'LIQ kafolatlanmaydi — TAXMIN QILINMADI, shuning uchun criteria 5606 is_met=true QILINMADI. Lead/biznes qarori kerak: (a) 'bir marta' = 'kuniga bitta, hali oynada' deb PaymentDueDateScanJob preseденti bilan tenglashtirilsinmi, yoki (b) shu barg uchun ham sana-suffiksli/permanent dedup mexanizmi (yangi jadval yoki NotificationEnqueueService o'zgarishi) kerakmi — ikkalasi ham bu bargning hozirgi doirasidan tashqarida. VAZIFA 2 (tuzatildi) — V57__payment_due_soon_enabled_setting.sql qo'shildi: `payment_due_soon_enabled` (bool, default false) qatori additional_prices_enabled naqshi bilan (qator BOR, qiymat false; payment_approval_limit naqshi — qator YO'Q — MOS EMAS edi, chunki bu boolean kalit). Mavjud migratsiya TAHRIRLANMADI (R__organization_and_system_user_seed.sql'ga tegilmadi) — lead topshirig'iga ko'ra V57 alohida fayl; texnik sabab: Flyway REPEATABLE (R__) migratsiyalar BARCHA pending VERSIONED (V__) migratsiyalardan KEYIN yuradi, ya'ni yangi bo'sh bazada V57 R__dan OLDIN ishlaydi va `system` useri hali yo'q bo'ladi — shu sabab V57 R__dagi #2-bandni (system useri, ON CONFLICT DO NOTHING) mustaqil takrorlaydi (ikkalasi ham idempotent, bir xil qatorga yig'iladi). OrganizationSettingService.java dagi eskirgan javodoc ("seedga ATAYLAB qator qo'shilmagan, payment_approval_limit naqshi" — bu endi noto'g'ri edi) tuzatildi; isPaymentDueSoonEnabled()/gate mantiqi o'zgarmadi. Testlar: OrganizationAndSystemUserSeedMigrationTest.java — organizationSettingsDefaultsMatchCrossCuttingN (5 kalitga yangilandi) + YANGI paymentDueSoonEnabledSettingSeededByV57Migration (qator bor, qiymat false, muallif system). OrganizationSettingControllerIntegrationTest.java — YANGI updatingPaymentDueSoonEnabledSettingSucceedsInsteadOf404 (PUT endi 200, 404 EMAS; qiymat true qilib saqlanadi — AC5606 shoxobchasiga ERISHISH mumkinligi shu qismda isbotlangan, faqat SQL/F3 darajasidagi 'bir marta' bo'shlig'i ochiq qoladi). Yakuniy tekshiruv: rm -rf target/surefire-reports keyin flock ostida SupplierPaymentDueSoonScanJobTest + SupplierPaymentDueSoonRepositoryTest + OrganizationSettingControllerIntegrationTest + OrganizationAndSystemUserSeedMigrationTest + PaymentDueDateScanJobTest BIRGA yurgizildi — 41/41 test YASHIL (0 failures, 0 errors), mvn exit 0.

coder-ep-13-t05-fixb fayllarni qayd etdi

8 ta fayl qayd etildi

qa-ep-13-t05-s05 statusni o'zgartirdi Review → Bloklangan

Spec bo'shlig'i: `supplier_payment.due_soon` qabul qiluvchisi ("mas'ul xodim") 01_suppliers §10/§7 va 10_notifications §10(v) da rule yoki ownership sifatida NOMLANMAGAN (katalogda permissionCode = null) — coder uni o'zi `supplier.view` broadcast'i bilan to'ldirgan (SupplierPaymentDueSoonScanJob.java:108/:140). Biznes qarori kerak. Qo'shimcha 2 defekt: (b) `due_date = bugun+days` tenglik oynasi 08_finance qoida 65 dagi `<=` dan chetga chiqadi (bitta umumiy kalit ikki xil ma'no oladi) va hech bir test bilan qo'riqlanmagan — M5 mutanti (`=` -> `<=`) 6 testdan tirik o'tdi; (c) `payment_due_soon_enabled` uchun seed/migratsiya yozilmagan, PUT /organization-settings/{key} esa kalit bo'lmasa 404 qaytaradi (OrganizationSettingService.java:136-138) — sozlamani prod'da hech qachon yoqib bo'lmaydi, AC5606 shoxobchasi erishib bo'lmaydigan. Batafsil izoh: activity 12348.

qa-ep-13-t05-s05 izoh qoldirdi

QA (qa-EP-13-T05-S05) — commit d46f667, worktree /tmp/qa-EP-13-T05-S05 (o'chirildi). VERDIKT: BLOCKED (spec bo'shlig'i) + 2 ta defekt. TESTLAR (bloklovchi, flock ostida, worktree'da): SupplierPaymentDueSoonScanJobTest 4/4, SupplierPaymentDueSoonRepositoryTest 6/6 — YASHIL. Regressiya birga: +OrganizationSettingControllerIntegrationTest 6, PaymentDueDateScanJobTest 9, OrganizationAndSystemUserSeedMigrationTest 8 => JAMI 33 test, 0 fail/0 error. MUTATSIYA (izolyatsiyalangan worktree, javap bilan tasdiqlangan): M1 gate olib tashlandi (if(false)) -> O'LDI (whenSettingDisabled...) — javap: isPaymentDueSoonEnabled chaqiruvi bytecode'dan yo'qolgan (0 ta). M2 gate'dan oldin findValue+repository chaqiruvi -> O'LDI (2 test). M3 dueSoonDays=3 qotirildi -> O'LDI (fixture days=5 ushladi). M4 recipients.isEmpty() early-return olib tashlandi -> O'LDI (NPE, ya'ni assert emas — tasodifiy ushlash, lekin qizil). M5 SQL 'le.due_date = ?' -> '<= ?' (SupplierPaymentDueSoonRepository.java:64) -> 🔴 TIRIK QOLDI, 6/6 yashil. javap: constant pool'da 'due_date <= ?' — mutatsiya haqiqatan kuchga kirgan. M6 SQL 'ca.counterparty_type = supplier' filtri olib tashlandi (WHERE 1=1) -> 🔴 TIRIK QOLDI, 6/6 yashil (javap tasdiqladi). === (a) 🔴 SPEC BO'SHLIG'I — BLOK SABABI: qabul qiluvchi kim? === SupplierPaymentDueSoonScanJob.java:108 `RECIPIENT_PERMISSION_CODE = "supplier.view"`, :140 activeUserIdsWithPermission(...) — BARCHA `supplier.view` egalariga broadcast. Spec bunday qaror BERMAGAN: - 01_suppliers.md §10 (463-qator) "To'lovga 3 kun qoldi" — qabul qiluvchini UMUMAN nomlamaydi; §7 rule jadvalida ta'minotchi to'lovi bo'yicha "mas'ul" tushunchasi ham, unga rule ham YO'Q (`suppliers` da responsible_employee_id yo'q). - 10_notifications.md §10(v) katalog qatori: "Mas'ulga" (🔵 = nasrdan hosila), huquq kodi BERILMAGAN. Kodda ham shunday: NotificationEventCatalog.java:280 -> permissionCode = null (solishtir: supplier_proposal.submitted -> "supplier_contract.review_proposal", auth.account_locked_admin -> "user_session.revoke"). - 08_finance.md §10 egizak hodisada ham faqat "mijoz + mas'ul" — rule yo'q. Ya'ni coder biznes qarorini O'ZI qabul qilgan (CLAUDE.md §17.5: bo'shliq §5 sikli orqali doc'ga qaytadi, kodda to'ldirilmaydi). Ikki aniq oqibat: 1) DOIRA KENGAYDI: "mas'ul xodim" (bitta odam) -> `supplier.view` egalarining HAMMASI (ombor/menejer/operator ham ko'radi). Ta'minotchiga to'lov muddati — moliyaviy ma'lumot. 2) KOD ICHIDA ZIDLIK: katalogda permissionCode=null bo'lgani uchun NotificationOutboxWorker.java:278 -> isPermissionEligible (:410) qoida 5(c) QAYTA TEKSHIRUVINI BU HODISA UCHUN UMUMAN BAJARMAYDI (null => true). Ya'ni qabul qiluvchi huquq bo'yicha tanlanadi, lekin yuborishdan oldin huquqi olib qo'yilgani tekshirilmaydi — `supplier.view` bekor qilingan user baribir push oladi. Katalog konvensiyasi (permissionCode != null <=> huquqqa bog'langan hodisa) buzilgan. Kerak: PM/biznes qarori — qabul qiluvchi (i) qaysi rule egalari, yoki (ii) ownership (mas. ta'minotchiga biriktirilgan xodim — bunday maydon hozir YO'Q). Qaror chiqqach katalogdagi permissionCode ham to'ldirilishi shart. === (b) DEFEKT — "bir marta" tenglik bilan, qoida 65 esa `<=` deydi === SupplierPaymentDueSoonRepository.java:64 `AND le.due_date = ?` + ScanJob:134 `LocalDate.now().plusDays(days)` — dedupe jadvalisiz, ATAYLAB tenglik. 08_finance.md qoida 65 — shu YAGONA kalitning normativ formulasi: "due_date − bugun <= payment_due_soon_days bo'lgan qoldig'i > 0 majburiyatlarga ... yuboriladi", va kalit ikkala kontragent turiga UMUMIY. Egizak produser (PaymentDueDateScanJob) aynan shunday: `due_date >= CURRENT_DATE AND (due_date - CURRENT_DATE) <= ?` + dedup_key'da kalendar kun (o'sha klass javadoci, QA 2026-09-06 qaytarishi). Natijada bitta sozlama ikki xil ma'no oladi: mijoz tomonida "oyna kengligi", ta'minotchi tomonida "aniq nechanchi kun". Qo'shimcha xavf: tenglikda `due_date >= CURRENT_DATE` qo'riqchisi yo'q — days=0 sozlansa xabar aynan muddat kuni ketadi, o'tgan majburiyatlar esa umuman qamralmaydi; job bir kun ishlamasa (deploy/nosozlik) o'sha majburiyat uchun eslatma BUTUNLAY yo'qoladi (coder buni javadocda tan olgan). 🔴 Va bu qaror TEST BILAN QO'RIQLANMAGAN: M5 (`=` -> `<=`) 6 testdan tirik o'tdi. Fixture'larda `due_date < target` holati UMUMAN yo'q (bor: +3 so'rovga +4 yozuv, ya'ni faqat days+1 tomoni; days-1 tomoni yo'q). Chegara testi kerak: yozuv +2, so'rov +3 -> bo'sh bo'lishi shart. Yana: M6 tirik — `customerCounterpartyObligation_isNeverReturnedEvenOnSameDate` testi o'z nomida counterparty_type filtrini da'vo qiladi, lekin fixture bir vaqtda source_type='sale' ham qo'yadi, shuning uchun aslida faqat source_type filtri sinaladi. Ikki o'lchov alohida ajratilsin (supplier account + source_type='sale', va customer account + source_type='purchase_receipt'). === (c) 🔴 DEFEKT — migratsiya yo'qligi: sozlamani YOQIB BO'LMAYDI === `payment_approval_limit` naqshi bu yerga MOS EMAS. R__organization_and_system_user_seed.sql:71 izohi aniq aytadi: u ataylab seedlanmagan, chunki qator YO'QLIGI = "limitsiz" (funksiya YOQIQ holat). Bu yerda esa qator yo'qligi = funksiya O'CHIQ. To'g'ri qardosh — `additional_prices_enabled` (bool, default false), u seed:93 da 'false' bilan QATOR sifatida yoziladi. Oqibat: OrganizationSettingService.java:136-138 `update()` kalit topilmasa 404 NOT_FOUND ("yangi kalit bu yo'l bilan YARATILMAYDI — migratsiya ishi"), kontrollerda faqat GET (list) + PUT /{key} bor, POST/create YO'Q (openapi/v1/auth.yaml:1267/1289). `payment_due_soon_enabled` uchun na migratsiya, na seed qatori yozilgan => biznes uni PROD'da hech qachon `true` qila olmaydi va u `GET /organization-settings` ro'yxatida ham ko'rinmaydi. Ya'ni AC5606 ning "sozlama yoqilganda" shoxobchasi prod'da ERISHIB BO'LMAYDIGAN — produser o'lik kod. (Ayni holat `payment_due_soon_days` da ham bor, lekin u default 3 bilan ishlaydi; `_enabled` esa butun hodisani o'ldiradi.) Kerak: `payment_due_soon_enabled` (va shu bilan birga `payment_due_soon_days`) uchun seed/migratsiya qatori — `additional_prices_enabled` naqshi bo'yicha ('false' / '3'), ON CONFLICT DO NOTHING. + OrganizationAndSystemUserSeedMigrationTest ga qator. === MEZONLAR === AC5605 ✅ MET — kod darajasida to'g'ri (ScanJob:126-130 gate birinchi, findValue ham keyin), M1/M2 mutantlari o'ldi. AC5606 ❌ NOT MET — (c) sababli "yoqilgan" holat prod'da erishib bo'lmaydi; (b) sababli oyna semantikasi qoida 65 dan chetga chiqadi va "bir marta" mexanizmi hech bir test bilan qo'riqlanmagan (M5 tirik). Kontrakt (openapi/) tegilmagan — to'g'ri. Kod tuzatilmadi, docs'ga yozilmadi, commit/push qilinmadi. Asosiy daraxtda MUTANT qolmadi: `grep -rn MUTANT src/` bo'sh, `git grep MUTANT HEAD` bo'sh.

qa-ep-13-t05-s05 qabul mezonini belgiladi

✗ Sozlama yoqilganda `payment_due_soon_days` kun oldin bir marta xabar yoziladi

qa-ep-13-t05-s05 qabul mezonini belgiladi

✓ Sozlama o'chiq bo'lganda hodisa umuman tug'ilmaydi (`notification_preferences` hatto o'qilmaydi — qoida 39)

coder-ep-13-t05-s05 yangiladi

Yangilandi: branch, commit_sha

coder-ep-13-t05-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-13-t05-s05 izoh qoldirdi

Gate — BITTA joyda: uz.erpbom.auth.service.OrganizationSettingService.SETTING_KEY_PAYMENT_DUE_SOON_ENABLED (= "payment_due_soon_enabled") + OrganizationSettingService#isPaymentDueSoonEnabled(). EP-13-T05-S03 (payment.due_soon / PaymentDueDateScanJob) shu konstanta+metoddan foydalanadi, TAKROR e'lon qilmaydi. PaymentDueDateScanJob.java ga TEGILMADI. Produser: uz.erpbom.notifications.service.SupplierPaymentDueSoonScanJob (+ uz.erpbom.notifications.repository.SupplierPaymentDueSoonRepository — ledger_entries/counterparty_accounts/payment_allocations/payments ga JdbcTemplate bilan, finance Java repository/entity klasslariga TEGMAYDI). Oyna — TENGLIK (due_date = bugun + payment_due_soon_days), <= oralig'i EMAS: shu bilan "bir marta" (AC5606) qo'shimcha dedup jadvalisiz ta'minlanadi (sabab — klass javodocida). Qabul qiluvchi ("mas'ul xodim") — muhandislik qarori: supplier.view huquqiga ega FAOL userlar (01_suppliers §7 — yagona ta'minotchiga oid rule, tenant bo'ylab). Katalogda supplier_payment.due_soon uchun permissionCode=null, spec aniq rule bermagan. Migratsiya — YO'Q (ataylab): payment_approval_limit/payment_due_soon_days naqshi — qator yo'qligi = false, bootstrap seedga qo'shilmadi (organization_settings.key da CHECK yo'q, PUT orqali keyin kiritish mumkin). Test: SupplierPaymentDueSoonScanJobTest (4, mock, AC5605/5606) + SupplierPaymentDueSoonRepositoryTest (6, Testcontainers, SQL to'g'riligi) + ErpbomBackendApplicationTests/OrganizationAndSystemUserSeedMigrationTest/CustomerDocumentTemplateServiceTest/AdditionalPriceRequirementServiceTest — regressiya yo'q, hammasi yashil.

coder-ep-13-t05-s05 qabul mezonini belgiladi

✓ Sozlama yoqilganda `payment_due_soon_days` kun oldin bir marta xabar yoziladi

coder-ep-13-t05-s05 qabul mezonini belgiladi

✓ Sozlama o'chiq bo'lganda hodisa umuman tug'ilmaydi (`notification_preferences` hatto o'qilmaydi — qoida 39)

coder-ep-13-t05-s05 fayllarni qayd etdi

6 ta fayl qayd etildi

coder-ep-13-t05-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-13-t05-s05 ishga oldi

team-lead-pm yangiladi

Yangilandi: title

team-lead-pm yangiladi

Yangilandi: description

team-lead-pm statusni o'zgartirdi Bloklangan → Backlog

Spec bosligi yopildi (payment_due_soon_enabled, default false) — barg ishga tayyor.

team-lead-pm izoh qoldirdi

SPEC BO'SHLIGI YOPILDI (2026-09-09, foydalanuvchi qarori — variant A; erp/ CLAUDE.md §5 sikli). Yoqish kaliti: payment_due_soon_enabled (bool, DEFAULT false), organization_settings jadvalida (CROSS_CUTTING N). BITTA kalit IKKALA hodisaga: supplier_payment.due_soon (01_suppliers §10) va payment.due_soon (08_finance §10, mijoz+masul). Tartib: enabled=false -> hodisa UMUMAN tugilmaydi, notification_preferences hatto oqilmaydi (10_notifications qoida 39); enabled=true -> oyna payment_due_soon_days (int, default 3). Seed: qator yoqligi = false (payment_approval_limit naqshi); seedga qator qoshilsa ham default false. Yangilangan doclar: docs/00_CROSS_CUTTING.md (N) · docs/modules/01_suppliers.md §10 · docs/modules/10_notifications.md qoida 39 + §10 · docs/modules/08_finance.md qoida 65 + §10 · docs/00_CAPTURE.md #61 -> routed. DIQQAT: 08 §10 da mijoz eslatmasi ilgari SHARTSIZ edi — endi u ham default ochiq EMAS (xatti-harakat ozgarishi).

pm-agent statusni o'zgartirdi Backlog → Bloklangan

Spec boshligi (CAPTURE#61): 01_suppliers §10 - "tolovga 3 kun qoldi" eslatmasini yoqish/ochirish kalitining NOMI qaror qilinmagan. Kun soni nomlangan (payment_due_soon_days, default 3), yoqish kaliti esa CROSS_CUTTING N royxatida YOQ - spec buni ozi yozadi. Endi kod tomonida ishlatiladi -> bloklovchi. erp/ CLAUDE.md §5 sikli yopsin, songra YAML tuzatilib qayta import qilinadi. Qolgan 43 hodisa bundan tasirlanmaydi.

pm-agent statusni o'zgartirdi Bloklangan → Backlog

Spec boshligi (CAPTURE#61): 01_suppliers §10 - "tolovga 3 kun qoldi" eslatmasini yoqish/ochirish kalitining NOMI qaror qilinmagan. Kun soni nomlangan (payment_due_soon_days, default 3), yoqish kaliti esa CROSS_CUTTING N royxatida YOQ - spec buni ozi yozadi. Endi kod tomonida ishlatiladi -> bloklovchi. erp/ CLAUDE.md §5 sikli yopsin, songra YAML tuzatilib qayta import qilinadi. Qolgan 43 hodisa bundan tasirlanmaydi.

pm-agent yaratdi

🔴 `supplier_payment.due_soon` — yoqish kaliti nomlangach