[waritctd]

Why

QA finding 2026-10-18 on the develop stack: a deal quoted through the new engine (POST /pricing-requests/{id}/deal-quotations, the only stage-advancing quotation path since #1153) reaches ขั้น 10 but cannot get a ใบแจ้งยอดเงินรับมัดจำ from the UI. Both DealDepositPanel and DepositNoticePage call POST /api/pricing-requests/{id}/deposit-notice, which read only LEGACY CustomerQuotation rows and answered 409 "ยังไม่มีใบเสนอราคาที่ลูกค้ายอมรับสำหรับคำขอราคานี้" for every such deal.

What changes (sales/CRM: API behaviour change, stated explicitly)

Contract changes on POST /api/pricing-requests/{id}/deposit-notice (OrderConfirmationService#createDepositNoticeFromQuotation):

1. With no ACCEPTED legacy quotation, it now falls back to THIS pricing request's ACCEPTED PRICING_REQUEST-origin (new-engine) quotation. Reference = that quotation's number; items = that quotation's sales.quotation_item lines; percent = that quotation's own deposit_percent (null → the existing per-ticket lookup, then 0.50).
2. A 0% ("ไม่รับมัดจำ") new-engine quotation answers 409 ใบเสนอราคา <no.> ระบุไม่มีมัดจำ (ชำระเต็มจำนวน) จึงออกใบแจ้งยอดเงินรับมัดจำไม่ได้ instead of drafting a 0-baht notice.
3. ISSUED-only still 409s with the original message. The legacy-quotation branch and the ticket-level route POST /api/tickets/{id}/deposit-notice/draft keep their previous behaviour (same per-ticket percent derivation, no 0% guard).

Files changed

• backend/.../dealquotation/DealQuotationRepository.java — new findAcceptedForPricingRequest (ACCEPTED, newest by id; "latest by id" is wrong because an open revision DRAFT can outrank the accepted row); corrected the false "no revision chain" Javadoc on findLatestForPricingRequest.
• backend/.../deposit/DepositNoticeRepository.java — findDealQuotationItems(quotationId) extracted from findDealQuotationItemsForDeposit (same SQL/mapper); findDealQuotationDepositPercent Javadoc corrected (engines are exclusive per pricing request, not per ticket).
• backend/.../deposit/DepositNoticeService.java — createDraftFromQuotation(ticketId, req, Integer sourceDepositPercent, actor); createDraft delegates with null; itemsFromDealQuotation(quotationId).
• backend/.../orderconfirmation/OrderConfirmationService.java — the new-engine branch + 0% guard described above.
• backend/src/test/.../DealQuotationOutcomeIntegrationTest.java — 6 new cases (below) + fixture overloads.
• frontend/src/api/mockApi.js — mirrors the PR route's new-engine branch, the 0% refusal, a findDealQuotationItems mapper, and the ticket-level new-engine item fallback.
• frontend/src/api/mockApi.depositNotices.test.js — 4 new cases (below), new-engine drive helpers.
• (Plan doc added in a32b02b was removed again in 06182e8 — the PR body is the handoff.)

Commands run

• cd backend && ./mvnw -B -q -Dtest=DealQuotationOutcomeIntegrationTest -Dtest.fork.count=1 test (real Postgres via Testcontainers)
• cd frontend && npx vitest run src/api/mockApi.depositNotices.test.js src/api/contract.test.js && npx eslint src/api/mockApi.js src/api/mockApi.depositNotices.test.js
• Full mvnw verify / npm test / npm run build: CI only (targeted runs locally).
• Clean-review pass (2 refactor commits, 3f3c3d4 + 59f623e: mock mapper reads the stored row, test fixture shrinks, Javadoc only). /code-review max run; findings carried into Known risks.
• Real-stack walk on the QA stack (jar at 06182e8, DB glr_qa_stages, deal 55): deal page สร้างใบแจ้งยอดเงินรับมัดจำ → draft with reference QT-2026-0036-1, 30% (the quotation's own), ออกเอกสาร → GLRD69004 ISSUED, no 4xx.

Tests / build results

• DealQuotationOutcomeIntegrationTest: 33/33 on 59f623e (integration tests RAN, real Postgres).
• vitest deposit-notices + contract: 15/15; eslint clean.
• CI on 59f623e: see checks (the earlier audit failure on 1d390bf was an npm advisory, not this change; develop's vite bump is merged in at b26e95c).

Authz evidence

No authz change. The PR route still runs requireOwner before any lookup; …_nonOwnerSales_cannotReach (real DB) pins 403 + no row for a non-owning sales user on the new-engine case. Note (pre-existing, not touched here, from the max review): the ticket-level draft route POST /api/tickets/{id}/deposit-notice/draft has no owner/viewer check — any sales user can draft on another rep's deal. Unverified by any test; needs its own fix.

Known risks (from /code-review max, all confirmed; none fixed here)

1. NULL deposit_percent on an ACCEPTED new-engine quotation bills 0.50 while the PDF printed 30% (renderer null→30). New on this route (develop 409'd), pre-existing on the ticket route. Needs an owner ruling: shared null→30 constant, or submit() refusing a null percent.
2. On a mixed ticket (legacy ACCEPTED on PR-A, new-engine ISSUED 30% on PR-B) the percent silently comes from PR-B's row — pre-existing per-ticket lookup behaviour; the corrected Javadoc now says so. Untested direction.
3. findDealQuotationItems copies raw qty/final_unit_price: EN per-sqm rows (pieces × per-sqm price), EN/USD rows (THB + 7% VAT hardcoded), NET-mode double rounding, and DEAL_DIRECT ADJUSTMENT rows (qty −1 → PUT 400) — all pre-existing on the ticket route, now reachable through this route for ACCEPTED PR-origin quotations.
4. recordOutcome has no open-revision guard (ACCEPTED Q1 + ISSUED Q2 possible); findForPricingRequest still picks newest-by-id and hides Q1's outcome controls once a revision exists — pre-existing since 84ebf7e (develop only).
5. 11 of 12 hand-wired OrderConfirmationService test instances never call wireDealQuotationRepository; an unwired instance answers the original 409 on the new-engine branch.
6. Mock divergences: the mock PR route still bills payload.depositPercent ?? 0.5 when the chosen quotation has no percent (Java ignores the payload), and its ticket-route 0% check keys on the cross-array picker.
7. Not independently deployable with feat(sales): pick the next party once a designer/owner quotation is sent; เสนอใบราคา opens the new-engine quotation #1168: a combined real-stack walk showed that after a designer acceptance no later party can accept (R8), so feat(sales): pick the next party once a designer/owner quotation is sent; เสนอใบราคา opens the new-engine quotation #1168's next-party flow dead-ends — feat(sales): pick the next party once a designer/owner quotation is sent; เสนอใบราคา opens the new-engine quotation #1168 is held for a ruling; this PR is safe alone.

Test coverage

Backend (DealQuotationOutcomeIntegrationTest, real Postgres):

• …_newEngineAcceptedQuotation_createsTheSameDraftTheTicketRouteWould — reference = accepted number, items/percent equal the ticket route's, one DEPOSIT_NOTICE_DRAFTED_FROM_QUOTATION event. Red before fix (409).
• …_newEngineAcceptedWithAnOpenRevisionDraft_stillDraftsFromTheAcceptedOne — Q2 DRAFT outranks Q1 by id; draft references Q1. Red before fix.
• …_newEngineAccepted_whenASiblingPricingRequestHasALegacyIssuedQuotation_draftsThisQuotationsLinesAndPercent — sibling legacy row (forged deposit_percent = 70) supplies neither lines nor percent; draft at 0.30. Red before fix (sibling's percent).
• …_newEngineAcceptedZeroDeposit_409AndNoDraft — 0% + fullPaymentTerm → 409, no row. Red before fix.
• …_newEngineIssuedNotAccepted_still409 and …_newEngine_nonOwnerSales_cannotReach — regression pins, green on develop too (ISSUED-only already 409'd; requireOwner fires before any lookup).
  Mock (mockApi.depositNotices.test.js): reference/items/percent/discount label from the accepted new-engine quotation (red before: 409); ticket-level createDraft reads the same new-engine lines (red before: no items); ISSUED-only still 409 (pin); 0% → 409 and no draft (red before: drafted).
  Deliberately NOT covered: legacy-ACCEPTED + v2 ISSUED sibling carrying a percent (pre-existing behaviour, risk 2); EN/USD/NET-rounding/ADJUSTMENT item shapes (risk 3, pre-existing); the ticket-level owner gap (pre-existing, needs its own authz PR); UI e2e (verified by the hand walk above, not by e2e-real).

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
demo-glr	Ready	Preview	Oct 22, 2026 7:43am UTC