`confirmed` posting — shartnoma snapshot + `due_date` + atomik kirim (§8.1)

finalize-ep-04 yangiladi

Yangilandi: commit_sha, pr_url

qa-ep-04-t04-s03 statusni o'zgartirdi Review → Bajarildi

qa-ep-04-t04-s03 izoh qoldirdi

QA qayta tekshiruv (qa-EP-04-T04-S03) — 3cf4f9e. VERDIKT: AC2465 yopildi, barg DONE. 1) DIFF DOIRASI TASDIQLANDI. `git show --name-only 3cf4f9e` = FAQAT src/test/java/uz/erpbom/warehouse/controller/PurchaseReceiptConfirmedPostingTest.java (4 qator: :209 fixture, :219, :220, :231 assert). PurchaseReceiptService.java oldingi review'dagi nusxa bilan bayt-ma-bayt bir xil (diff bo'sh) — prod kod va migratsiya TEGILMAGAN. 820c7a6..3cf4f9e oralig'idagi src/main/java o'zgarishlari faqat WarehouseVariantSetting* (parallel worker'ning b4faf00 commit'i), bu bargga aloqasi yo'q. 2) MUTATSIYA TEKSHIRUVI — AC2465 ning TO'RT maydoni HAM alohida-alohida qoplanganini isbotladim. Har mutatsiya PurchaseReceiptService.java ga vaqtincha qo'yildi, PurchaseReceiptConfirmedPostingTest yurgizildi, so'ng `git checkout -- <aynan o'sha bitta fayl>` bilan tiklandi (checkout . / stash / reset ISHLATILMADI). A) `findActiveForUpdate(...)` -> eng eski shartnoma (ya'ni v1) o'qiladigan qilib almashtirildi => O'LDI: expected: 2L but was: 1L (contract_id v2 emas v1 bo'lib qoldi). Bu AC2465 ning asosiy mazmuni: snapshot manba obyekti confirm PAYTIDAGI faol (v2) shartnoma. B) `receipt.setPaymentBasis(activeContract.getPaymentBasis());` (PurchaseReceiptService.java:504) olib tashlandi => O'LDI: expected: "on_sale" but was: "on_receipt". OLDINGI REVIEW'DAGI TIRIK MUTANT ENDI O'LADI. C) `receipt.setPaymentMethodSnapshot(...)` olib tashlandi => O'LDI: expected: "mixed" but was: "null". D) `receipt.setTermDaysSnapshot(...)` olib tashlandi => O'LDI: expected: 45 but was: 0. E) `receipt.setContractId(...)` olib tashlandi => O'LDI: expected: 2L but was: 0L. Fixture endi to'rt maydonda ham v1 dan farq qiladi (v1 = transfer/10/on_receipt, v2 = mixed/45/on_sale) va draft default'idan ham (payment_basis DEFAULT_PAYMENT_BASIS='on_receipt') — shuning uchun har assert v1 ga ham, "umuman yozilmagan" holatga ham javob beradi. 3) TESTLAR (flock /var/tmp/erpbom-db.lock ostida, mvn -Dtest=PurchaseReceipt*Test test) — mutatsiyalar tiklangandan keyin: PurchaseReceiptConfirmedPostingTest 6/6, PurchaseReceiptCreateAndUpdateTest 15/15, PurchaseReceiptStateMachineTest 7/7, PurchaseReceiptsAndSupplierReturnsMigrationTest 5/5 — 33/33 yashil, mvn exit=0. Ish daraxti tekshirildi: bu bargning fayllari HEAD bilan bir xil, mutatsiya qoldig'i yo'q. Eslatma (kod muammosi EMAS): mutatsiya A ning BIRINCHI yurishi 6 ta Error bilan yiqildi — NoClassDefFoundError: uz/erpbom/products/dto/VariantSummary, ya'ni parallel worker'ning bir vaqtdagi build'i target/classes ni yarim holatda qoldirgan edi. `mvn -DskipTests clean compile` dan keyin qayta yurgizildi va yuqoridagi toza natija olindi. 4) YAKUN: 7/7 mezon o'tdi -> status = done. TAVSIYA (bloklamaydi, keyingi bargga yoki texnik qarzga): (a) 2 qatorli faktura uchun stock_batches=2 / purchase_in=2 va source_ref_id=receipt.id + partiya unit_cost assert'i yo'q — hozir "har qator uchun" faqat AC2469 dagi totalPayable yig'indisi orqali bilvosita qoplangan; (b) AC2466 dagi aniq misol (2026-09-01 + 30 -> 2026-10-01) qotirilgan sana bilan alohida assert qilinsa kuchliroq bo'ladi (hozirgi test kutilgan qiymatni javobning o'zidan hisoblaydi, lekin off-by-one mutatsiyasini ushlaydi — tekshirilgan).

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ `draft` da v1 shartnoma bo'lib, confirm paytida v2 faol bo'lsa snapshot v2 dan olinadi (`contract_id`, `term_days_snapshot`, `payment_method_snapshot`, `payment_basis`)

coder-ep-04-t04-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-04-t04-s03 yangiladi

Yangilandi: commit_sha

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `draft` da v1 shartnoma bo'lib, confirm paytida v2 faol bo'lsa snapshot v2 dan olinadi (`contract_id`, `term_days_snapshot`, `payment_method_snapshot`, `payment_basis`)

coder-ep-04-t04-s03 fayllarni qayd etdi

1 ta fayl qayd etildi

coder-ep-04-t04-s03 ishga oldi

qa-ep-04-t04-s03 izoh qoldirdi

QA (qa-EP-04-T04-S03) — 81398e2 / 820c7a6, branch feat/EP-04-erpbom-backend. TESTLAR (flock ostida, mvn -Dtest=PurchaseReceipt*Test test): PurchaseReceiptConfirmedPostingTest 6/6, PurchaseReceiptCreateAndUpdateTest 15/15, PurchaseReceiptStateMachineTest 7/7, PurchaseReceiptsAndSupplierReturnsMigrationTest 5/5 — hammasi yashil. MUTATSIYA TEKSHIRUVI (uchtasi, har birida fayl git checkout bilan tiklandi): 1) due_date: plusDays(termDays) -> plusDays(termDays+1) => O'LDIRILDI (confirmSnapshots... expected 2026-10-05 but was 2026-10-06). AC2466 jonli. 2) submit() @Transactional -> @Transactional(noRollbackFor=RuntimeException.class) => O'LDIRILDI (confirmFailureOnSecondLineRollsBackFirstLineToo). Atomiklik testi haqiqiy DB rollback'ini tekshiradi (arxivlangan variant -> VARIANT_ARCHIVED, so'ng purchase_receipts.status/contract_id/due_date + stock/batches/movements DB'dan o'qib tekshiriladi) — mock exception emas. 3) PurchaseReceiptService.java:504 `receipt.setPaymentBasis(activeContract.getPaymentBasis());` butunlay olib tashlandi => MUTANT TIRIK QOLDI, 6/6 test yashil. Bu AC2465 defekti (pastda). [X] AC2465 YIQILDI — snapshot testi 4 maydondan faqat 2 tasini isbotlaydi. Fayl: src/test/java/uz/erpbom/warehouse/controller/PurchaseReceiptConfirmedPostingTest.java:209 (va assert'lar 219-220-qatorlar). * :209 `replaceActiveContractWithNewVersion(supplierId, 45, "transfer", "on_receipt")` — v2 ning payment_method va payment_basis'i v1 bilan AYNI (v1 = insertSupplierWithContract("transfer", 10), payment_basis 'on_receipt' hardcode :433). * Ustiga, purchase_receipts.payment_basis yaratishda ham 'on_receipt' (PurchaseReceiptService.java:207 DEFAULT_PAYMENT_BASIS). * Natija: :219 `payment_method_snapshot == "transfer"` va :220 `payment_basis == "on_receipt"` — v1 dan olinsa ham, supplier cache'dan olinsa ham, umuman yozilmasa ham O'TADI (mutatsiya 3 buni isbotladi). Faqat contract_id va term_days_snapshot v1/v2 ni ajratadi. * Kutilgan: AC2465 ning to'rt maydoni ham v2 dan kelgani isbotlansin. TUZATISH (test-only, prod kodga tegilmaydi): * :209 -> `replaceActiveContractWithNewVersion(supplierId, 45, "mixed", "on_sale")` ('mixed' va 'on_sale' V12 CHECK'da ruxsat etilgan: chk_supplier_contracts_payment_method / _payment_basis). * :219 -> `.isEqualTo("mixed")`, :220 -> `.isEqualTo("on_sale")`, :231 (recorded.paymentBasis) -> `"on_sale"`. * So'ng mutatsiya 3 ni qayta yurgizib mutant o'lishini ko'ring. QOLGAN 6 MEZON O'TDI (kod darajasida tekshirildi): * AC2463 — PurchaseReceiptService.java:453-467 postIn(condition=good, sourceType=purchase, sourceRefId=receipt.getId(), totalCost=qty*unit_cost); test qty_on_hand=6.0000, stock_batches(source_type='purchase')=1, stock_movements(movement_type='purchase_in', direction='in')=1. qty_on_hand '+=' semantikasi T02 StockInPosterTest#postInCreatesBatchWithMatchingRemainingFieldsAndIncrementsExistingQtyOnHand (AC2431/2432) da qoplangan. * AC2464 — mutatsiya 2 bilan tasdiqlandi. * AC2466 — mutatsiya 1 bilan tasdiqlandi (document_date '2026-08-20' vs confirm sanasi farq qilgani uchun noto'g'ri baza ham ushlanadi). * AC2467 — kurs confirm'dan KEYIN UPDATE qilinadi, so'ng GET /{id} DB'dan qayta o'qiladi: exchange_rate 12800.000000 / unit_cost 640000.00 o'zgarmaydi. * AC2468 — PUT confirmed -> 409 INVALID_STATUS_TRANSITION (kontrakt: warehouse.yaml PurchaseReceiptConflict), qoldiq ham tegilmagan. * AC2469 — supplierLedgerPort.onPurchaseReceiptConfirmed(...) postConfirmation() oxirida, ya'ni submit()/overrideConfirm() ning @Transactional chegarasi ICHIDA (PurchaseReceiptService.java:276, :318, :470-471); NoopSupplierLedgerPort da TODO(08_finance) izohi bor; RecordingSupplierLedgerPort @Primary mock bilan amount=9000.00 / due_date / payment_basis tasdiqlandi. CROSS-CUTTING: @Transactional hamma DB metodida (o'qish readOnly=true); tenant_id/schema almashtirish yo'q; status hech bir request DTO'da yo'q — o'tishlar faqat alohida POST /submit, /confirm, /cancel; §4.1 ning 5 qiymati PurchaseReceiptService.java:87-95 da konstanta; kontraktdan chetlanish topilmadi; parol/token log'ga chiqmaydi; fizik DELETE yo'q. TAVSIYA (blok emas, keyingi bargga qoldirilishi mumkin): (a) 2 qatorli faktura uchun stock_batches=2 / purchase_in=2 va source_ref_id=receipt.id, batch unit_cost assert'i yo'q — hozir faqat AC2469 dagi totalPayable yig'indisi bilvosita qoplaydi; (b) AC2466 dagi aniq misol (2026-09-01 + 30 -> 2026-10-01) qotirilgan sana bilan alohida assert qilinsa kuchliroq bo'ladi.

qa-ep-04-t04-s03 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-04-t04-s03 qabul mezonini belgiladi

✗ `draft` da v1 shartnoma bo'lib, confirm paytida v2 faol bo'lsa snapshot v2 dan olinadi (`contract_id`, `term_days_snapshot`, `payment_method_snapshot`, `payment_basis`)

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ `SupplierLedgerPort` chaqirilgan (mock bilan tasdiqlanadi) va uning no-op implementatsiyasi 08_finance uchun TODO izohi bilan belgilangan

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ `confirmed` faktura qatorlarini tahrir/o'chirishga urinish rad etiladi (qoida 12)

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ `confirmed` dan keyin `exchange_rates` dagi kursni o'zgartirish faktura qatorining `exchange_rate`/`unit_cost` iga ta'sir qilmaydi (freeze)

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ `due_date = date(supplier_confirmed_at) + term_days_snapshot` aniq hisoblanadi (misol: 2026-09-01 + 30 → 2026-10-01)

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ Posting o'rtasida sun'iy xato yuz berganda hech narsa yozilmaydi (faktura holati va qoldiq o'zgarmaydi) — yarim yozilish yo'q

qa-ep-04-t04-s03 qabul mezonini belgiladi

✓ `confirmed` da har qator uchun yangi `stock_batch` (`source_type='purchase'`) va `purchase_in` movement yoziladi, `stock.qty_on_hand` aniq `+qty` oshadi

coder-ep-04-t04-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-04-t04-s03 yangiladi

Yangilandi: branch, commit_sha

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `SupplierLedgerPort` chaqirilgan (mock bilan tasdiqlanadi) va uning no-op implementatsiyasi 08_finance uchun TODO izohi bilan belgilangan

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `confirmed` faktura qatorlarini tahrir/o'chirishga urinish rad etiladi (qoida 12)

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `confirmed` dan keyin `exchange_rates` dagi kursni o'zgartirish faktura qatorining `exchange_rate`/`unit_cost` iga ta'sir qilmaydi (freeze)

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `due_date = date(supplier_confirmed_at) + term_days_snapshot` aniq hisoblanadi (misol: 2026-09-01 + 30 → 2026-10-01)

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `draft` da v1 shartnoma bo'lib, confirm paytida v2 faol bo'lsa snapshot v2 dan olinadi (`contract_id`, `term_days_snapshot`, `payment_method_snapshot`, `payment_basis`)

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ Posting o'rtasida sun'iy xato yuz berganda hech narsa yozilmaydi (faktura holati va qoldiq o'zgarmaydi) — yarim yozilish yo'q

coder-ep-04-t04-s03 qabul mezonini belgiladi

✓ `confirmed` da har qator uchun yangi `stock_batch` (`source_type='purchase'`) va `purchase_in` movement yoziladi, `stock.qty_on_hand` aniq `+qty` oshadi

coder-ep-04-t04-s03 fayllarni qayd etdi

6 ta fayl qayd etildi

coder-ep-04-t04-s03 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-04-t04-s03 ishga oldi

pm-agent bog'liqlik qo'shdi

→ EP-04-T04-S02

pm-agent yaratdi

`confirmed` posting — shartnoma snapshot + `due_date` + atomik kirim (§8.1)