Skip to content

[16.0][IMP] purchase_request_advance_payment: apply reimbursement rules for เงินยืม - #1257

Open
PiyaChaiyanit wants to merge 5 commits into
16.0from
16.0-imp-purchase_request_advance_payment
Open

PiyaChaiyanit wants to merge 5 commits into
16.0from
16.0-imp-purchase_request_advance_payment

Conversation

@PiyaChaiyanit

Copy link
Copy Markdown
Collaborator

Summary

Applies the same reimbursement rules already used for payment_type=prepaid (สำรองจ่าย, PR #1236) to payment_type=advance (เงินยืมทดรอง): the vendor must be an internal person (partner_type_id.is_internal), procurement_mode is locked to ผู้ขอระบุเอง, and vat_included is forced to exclusive.

Locks route through the shared is_vat_editable / is_procurement_mode_editable compute extension points (extended via super()) — no view-attrs stacking — plus an @api.constrains shell guard. A helper banner mirroring the prepaid one is added on purchase.request, and kmitl_demo records/E2E cases with payment_type=advance are repointed to internal partners so the new constraint passes on install.

Test plan

  • On a purchase request, cycle payment_type: direct unrestricted; prepaid unchanged; advance locks partner to internal, procurement_mode readonly on ผู้ขอระบุเอง, vat_included readonly on exclusive and shows the banner
  • Shell bypass on advance PR: write({'procurement_mode': 'by_officer'}), write({'vat_included': 'inclusive'}), write({'partner_id': <external>}) each raise ValidationError mentioning เงินยืมทดรอง
  • kmitl_demo installs cleanly (XML data + hooks.py E2E cases)

Sunny added 4 commits September 4, 2026 18:16
… เงินยืมทดรอง

Same triple as purchase_request_prepaid but gated on payment_type=advance:
vendor restricted to internal personnel (partner_type_id.is_internal),
procurement_mode locked to ผู้ขอระบุเอง, and vat_included forced to
exclusive. Enforced via extended onchange + a new @api.constrains; the
partner_id domain plugs into purchase_request_kmitl's shared extension
point via super(). No dep on purchase_request_prepaid.
…epaid pattern)

purchase_request_advance_payment now applies the same internal-only vendor
rule to payment_type=advance as prepaid does. All demo PRs with
payment_type=advance previously pointed partner_id at external vendor
companies, tripping the new constraint on install. Repoint each via
search on user_ids = requested_by (same pattern already used for prepaid
records in these files).

Covers 4 records in purchase.request.xml and 9 in
purchase.request.dashboard.demo.xml.
Mirror the existing prepaid warning banner for payment_type=advance:
"กรณีเลือกประเภทการจ่ายเงินเป็นเงินยืมให้เลือกชื่อผู้ยืมเงิน".

The English source matches the pre-existing msgid in i18n/th.po; the
Thai msgstr is polished from "ชื่อยืมเงิน" to "ชื่อผู้ยืมเงิน".
purchase_request_advance_payment applies the same internal-only vendor
rule to payment_type=advance as prepaid. Widen the existing conditional
so E2E cases with advance don't trip the constraint on install.
@PiyaChaiyanit PiyaChaiyanit changed the title [16.0][IMP] purchase_request_advance_payment: apply reimbursement rules for เงินยืมทดรอง [16.0][IMP] purchase_request_advance_payment: apply reimbursement rules for เงินยืม Sep 5, 2026
@PiyaChaiyanit PiyaChaiyanit added the status/ready-for-review Status: Issue is up for grabs label Sep 5, 2026
Comment on lines +23 to +27
def _compute_partner_id_domain(self):
super()._compute_partner_id_domain()
for rec in self:
if rec.payment_type == "advance":
rec.partner_id_domain = [("partner_type_id.is_internal", "=", True)]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ต้องใส่ @api.depends

…partner_id_domain

Match the base compute signature in purchase_request_kmitl so overrides
follow the same explicit-depends convention.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status/ready-for-review Status: Issue is up for grabs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants