# W1-PUR — Attachments on purchase request/order · supplier advance payment [FIN] (full-stack, Purchases/Accounting)

Migration timestamp range: `2026_11_25_700001…700099`. Read `_COMMON.md` first. [FIN] for the advance part — Fable reviews your diff.

## 1. Attach images/files to purchase request + purchase order (client: «إمكانية إرفاق صورة داخل طلب الشراء وأمر الشراء»)
Today: generic attachments `Core/app/Models/Attachment.php` (table `attachments`, private disk, 10MB, perms `core.attachments.*`, routes `Core/routes/api.php:143-146`; images blocked only for Product in `StoreAttachmentRequest.php:42-80`). Reusable FE widget `shared/components/entity-attachments/entity-attachments.component.ts` (jpg/png/webp/pdf), used in `partners.component.html:469` and the clinic visit. Nothing in Modules/Purchases uses attachments.
Build: register PurchaseRequest + PurchaseOrder (+ RFQ and purchase bill too if it's the same 3-line wiring — cheap and consistent) as attachable (morph map / allowed types list), `attachments()` relation + `attachments_count` in their resources; FE: the attachments widget inside the PR and PO create/edit/view dialogs (camera-friendly: accept images, `capture` on mobile), a 📎 count badge in the list rows, and when a PO is created from a PR offer to carry the PR's attachments (copy links or show «مرفقات الطلب» read-only on the PO). Make sure permissions are granted to purchasing roles (bridge migration if core.attachments.* isn't already granted to them).

## 2. Supplier advance payment (client: «إمكانية عمل دفعة مقدمة لمورد»)
Today: Purchases payment requires `bill_id` (`StorePurchasePaymentRequest.php:19`; `BillPaymentApplier.php` caps at the bill's open amount). Accounting payment voucher needs only `partner_id`, allocations optional (`StorePaymentVoucherRequest.php:25,54`; `VoucherAllocations.php:9-24`); unapplied remainder stays on the supplier AP (`ApprovePaymentVoucher.php:155-157`) and shows as `advances` (`PartnerCenterService.php:252,313`). No supplier-advance account setting (only customer advance accounts in `DefaultAccountExpectations.php:67-69`). No «apply advance to bill» action — needs a manual JE today. Deposits can't link to a PO.
Build:
- «دفعة مقدمة لمورد» action in Purchases (supplier screen + PO view «سداد دفعة مقدمة»): creates a supplier payment without a bill, optionally linked to a purchase order (`purchase_order_id` on the payment/voucher — migration), using the existing payment-voucher engine (approve → GL).
- Optional separate account: default account `purchases.supplier_advance_account_id` («دفعات مقدمة للموردين», asset) in default-accounts config/setup. If set: advance posts Dr supplier-advances / Cr cash-bank; applying it to a bill posts Dr AP (supplier) / Cr supplier-advances. If not set: advance posts Dr AP (debit balance, today's behaviour) and applying is a pure allocation (no GL).
- «تسوية دفعة مقدمة» on the purchase bill (view + when posting a bill for a PO that has advances, prompt «يوجد دفعة مقدمة X — خصمها من الفاتورة؟»): applies open advances (FIFO or picked) to the bill, reduces the bill's open amount, records an allocation row (reuse VoucherAllocations / open-items mechanism), reversible (unapply). Bill + supplier statement show the applied advance.
- Supplier screen: open advances balance + list.
- Tests: advance with/without separate account (GL balanced), apply to bill (open amount, GL), unapply reversal, cannot over-apply, PO link.

Out of scope: customer advances (exist), POS.