Payment terms module — JetSetGo MCP reference

The paymentterms module defines when customers are invoiced and when payment is due. A payment term combines three parts: an invoice trigger (an anchor date plus a day offset determining when a booking becomes ready to invoice), an invoice frequency (daily, weekly or monthly batching), and a due window expressed as days after the invoice date. Clients reference a payment term, so these definitions drive the invoicing rhythm for entire customer relationships.

What the operator uses it for

Operators encode each commercial arrangement as a reusable named term. For example, a term might declare that a booking is ready to invoice a fixed number of days before the travel date, that invoices are batched weekly on a chosen weekday, and that payment is due a set number of days after issue. Another might batch monthly on a chosen day of the month with no explicit trigger. The trigger anchor can be the travel date or the booking date; any component that does not apply to an arrangement is simply left unset.

Once defined, a term is attached to clients in the clients module; from then on, invoice batching treats that client's bookings according to the term.

Where it sits

This is a pure reference table with no upstream dependencies of its own. Downstream, the clients module attaches terms to customer records, and the accounting-operations side — previewing and executing invoice batches — consumes the terms but belongs to the glrules module, not this one. Bookings supply the travel dates that trigger-based terms anchor against.

Key concepts

Invoice trigger — an anchor (travel date or booking date) plus a day offset marking when a booking is ready to invoice.
Trigger days — the offset applied to the anchor; negative offsets typically mean "before" the anchor.
Invoice frequency — how often invoices are batched: daily, weekly, monthly, or unset.
Invoice weekday — required for weekly frequency; the day of week invoices are issued.
Invoice month-day — required for monthly frequency; a day of month from 1 to 31.
Pay-within window — days after the invoice date when payment is due.
Soft delete — retirement that preserves history; listings exclude deleted terms.

Tools

Tool	Class	Purpose
`paymentterms_list`	Read	List non-deleted payment terms ordered by name.
`paymentterms_get`	Read	Fetch one payment term by id.
`paymentterms_save`	Guarded write	Create or update a payment term with conditional validation; updates accept any subset and revalidate.
`paymentterms_delete`	Guarded write	Soft-delete a payment term (reversible).

Rules worth knowing

A name is always required, non-empty after trimming.
Conditional requirements are enforced: weekly frequency demands an invoice weekday; monthly frequency demands a month-day between 1 and 31; setting a trigger anchor demands trigger days.
Updates are validated against the effective field set: supplied values override current values, and conditional rules are re-checked after merging — so clearing a frequency without clearing its weekday fails rather than leaving inconsistent data.
Everything else is optional: a term may carry only a due window, only a frequency, or any partial combination, as long as conditionals hold.
Deletion is soft and reversible, and lists exclude deleted rows.
Invoicing execution lives elsewhere: this module defines terms only; the invoice-batch preview/execute/export operations belong to the glrules module.

Clients — attach a payment term to each customer record.
General ledger rules — owns invoice-batch dispatch, which consumes these terms.
Bookings — travel and booking dates anchor trigger calculations.
Invoices — the documents produced when batches run under a term's schedule.