# Purchase Payment Terms

## Overview

Purchase Payment Terms defines how supplier invoices become due once commercial purchasing is complete. A `PurchasePaymentTerm` models rules such as net days, end-of-month due dates, and installment splits. These terms can default onto purchase orders from the supplier's purchasing profile and flow forward into `PurchaseBill` so that the bill carries the expected supplier settlement schedule when handed off to accounts payable.

The feature is intentionally limited to supplier-facing payable terms within procurement. It does not execute payment runs or post accounting entries. Instead, it standardizes the contractual timing information that purchasing and accounts payable both need.

## Business Purpose

- Standardize supplier settlement expectations across purchase orders and supplier bills
- Reduce manual bill-entry work by defaulting due-date schedules from negotiated payment terms
- Support installment or staged payment structures for large or milestone-based purchases
- Provide consistent payment timing rules that downstream accounts-payable can reference
- Separate payment timing rules from supplier master data so terms can evolve independently per transaction or agreement

## Process Flow

```mermaid
flowchart TD
    A[Define Purchase Payment Term] --> B[Configure schedule lines]
    B --> C[Activate term]
    C --> D[Assign term to PO at creation time]
    D --> E[Supplier Bill created from order or entered manually]
    E --> F[Copy payment term snapshot to bill]
    F --> G[Calculate due dates and installment amounts]
    G --> H[Bill becomes ready for downstream AP processing]
```

## Scenario Patterns

- **Net 30 standard term**: A supplier agreement states payment is due 30 days after the invoice date, and every bill using that term receives a single due date 30 days later
- **Supplier default term propagation**: A supplier is configured with a default purchase payment term, and each new draft PO starts with that term before the buyer decides whether to override it
- **Installment schedule**: A capital purchase requires 30 percent upfront and 70 percent after delivery. The payment term expresses two due schedule lines rather than a single maturity date
- **End-of-month settlement**: Bills dated throughout the month become due at month end plus a fixed number of days, matching supplier accounting policy
- **Term override for one PO**: A buyer uses the supplier's usual net 45 term on most orders but overrides a specific order to net 15 because of a negotiated expedited arrangement
- **Term retirement**: An old payment term is deactivated when the supplier contract is renegotiated, but historical orders and bills retain the prior snapshot
- **Manual supplier bill entry**: A bill is entered directly against a PO and inherits its purchase payment term even if no automatic bill generation exists
## Test Cases

- Creating a purchase payment term with at least one schedule line should succeed
- The sum of installment percentages on a percentage-based payment term must equal 100 percent
- A payment term schedule line must not allow a negative percentage or negative fixed amount
- Inactive payment terms must not be assignable to new purchase orders or new supplier bills
- A payment term must be specified when creating a new draft purchase order; the caller (application layer or UI) may resolve a default from the supplier profile but the module requires an explicit value
- A purchase order should snapshot its assigned payment term so later edits do not alter existing downstream bills
- A supplier bill due-date schedule must be computable from the bill date and the assigned payment term
- End-of-month terms must produce a due date based on calendar month logic rather than a simple fixed-day offset
- Installment terms should generate multiple due schedule lines on the supplier bill
- A payment term can be overridden on a draft purchase order but changing it after matched billing should be prevented or explicitly controlled
- Purchase payment terms must be isolated by company when procurement policies differ by legal entity
- Deactivating a payment term that is already referenced historically must preserve existing order and bill snapshots
- Only authorized procurement or finance users should be able to create, update, activate, or deactivate payment terms

## Reference Links

- [Odoo payment terms documentation](https://www.odoo.com/documentation/19.0/applications/finance/accounting/customer_invoices/payment_terms.html)
- [Oracle Fusion Cloud Financials and procurement documentation](https://docs.oracle.com/en/cloud/saas/index.html)
- [SAP S/4HANA Cloud documentation](https://help.sap.com/docs/SAP_S4HANA_CLOUD)
