Reference "Payment Schedules" (Catalogs.ГрафикиОплаты) — Technical Description

1. Object Identification

Purpose. "Payment Schedules" is a classifier that includes all payment schedules applied at the enterprise. The catalog stores templates for splitting the document amount (order, contract, agreement) into payment stages — advance, prepayment before shipment, payment on fact, and deferral (credit) with an indication of the share of each stage and its due date. The payment schedule is substituted into sales/purchase documents and into agreements with customers and suppliers, after which the system automatically calculates a payment calendar (planned dates and amounts) and controls overdue debt.

This is a reference/master data object: it is not posted and does not generate movements itself — it sets the rules by which planned amounts are "spread" across dates in consuming documents.

2. Header Attributes and Tabular Sections

2.1. Header attributes

2.2. Tabular section "Stages" (ЭтапыОплаты)

The core of the object — stage rows, each describing one planned part of the payment.

Correctness control: the sum of percentages across stages = 100%; when Детализировать = False there is only one row.

3. Forms

4. Key Module Procedures

For the "Payment Schedules" catalog, no separate application-level evidence with BSL code is attached (only the purpose facet is present in the source data). Below are the typical handlers for this object type in UT/UNF configurations; exact procedure names should be verified in the configurator of the target release.

Object module (ОбработкаПроверкиЗаполнения)

• Verification that the name is filled and the stages table is not empty when Детализировать = True.
• Check that the total Процент across the ЭтапыОплаты rows equals 100.

Item form module

• ПриСозданииНаСервере — initializes visibility of stage columns depending on the detail flag.
• ДетализироватьПриИзменении — enables/disables the stages table; when disabled — collapses into a single "100%" stage.
• ЭтапыОплатыПроцентПриИзменении — recalculates and indicates the remaining amount up to 100%.
• ВариантОплатыПриИзменении — manages availability of due-date fields (for the "Advance/Prepayment" variant the countdown is usually from the order date, for "Credit" — from the shipment date).

Program interface (common calculations module, e.g. РасчётыСКлиентамиСервер/РасчётыСПартнёрами)

• A function to build a payment calendar based on the selected schedule: input — amount and reference document date, output — table "Stage / Date / Amount".

5. Posting and Movements

The catalog is not a document and is not posted — it does not generate its own register movements or accounting entries. Its role is to serve as a source of rules for consuming documents. Below is how the schedule participates in accounting through these documents (figures and accounts — for Kazakhstan, 2026).

Payment calendar and settlements. When a schedule is substituted into an order/sale/agreement, the system calculates planned dates and amounts by stage and records them in settlement registers (customer/supplier settlements, aging debt). This data feeds accounts receivable/payable reports and overdue debt control.

Example of sales document entries using a schedule (sale for 1,160,000 ₸ including VAT 16%):

• Dt 1210 "Short-term receivables from customers" — Ct 6010 "Revenue from sales" — 1,000,000 ₸ (amount excluding VAT);
• Dt 1210 — Ct 3130 "VAT payable" — 160,000 ₸ (VAT 16%);
• Dt 7010 "Cost of sales" — Ct 1330 "Goods" — for the cost amount.

Example of stages of the "Advance 30% + 70% deferral 10 days" schedule for this amount:

• Stage 1 (Advance, 30%): planned amount 348,000 ₸ as of the order date → upon payment, Dt 1030 — Ct 1210 (or advances received account);
• Stage 2 (Credit, 70%): planned amount 812,000 ₸ as of "shipment + 10 days".

Purchases. For supplier payment schedules, planned accounts payable are calculated similarly (account 3310 "Accounts payable to suppliers"), payment — Dt 3310 — Ct 1030.

Electronic documents. The schedule itself is not exported to the ESF (ESF IS) or SNT — these documents are generated based on the sale/invoice; the schedule only determines the payment due dates in the primary document.

Payroll/tax accruals (IIT 10%/15%, 30 MCI deduction, OPV 10%, OPVR 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6%; MCI 4,325 ₸, minimum wage 85,000 ₸) are not related to this catalog and are provided only as current regulatory context for Kazakhstan 2026 — they are not used in payment schedules.

6. Related Objects and Entry on Basis

Consuming objects (where the schedule is selected):

• Справочник.СоглашенияСКлиентами / СоглашенияСПоставщиками — default schedule for deals;
• Справочник.Договоры (counterparties) — contract payment terms;
• Order and sales/receipt documents — ЗаказКлиента, ЗаказПоставщику, РеализацияТоваровУслуг, ПоступлениеТоваровУслуг (attribute "Payment Schedule" / "Payment Stages").

Related enumerations: ВариантыОплаты (Advance/Prepayment/Credit), ФормыОплаты (cash/non-cash/card).

Entry on basis. For a reference/master data object, entry on basis is generally not provided: the schedule is created manually in the list and then selected in documents. If needed, a schedule can be copied as a base for a new one.

7. Extension Points

• Additional attributes and information (the "Properties" subsystem) — for industry-specific schedule analytics without modifying the configuration.
• Configuration extensions — adding header/stage attributes, overriding list and item forms, adding server-side fill-check handlers.
• Event subscriptions and intercepting ОбработкаПроверкиЗаполнения — for custom rules (e.g., prohibiting schedules with a percentage sum ≠ 100 or limiting maximum deferral).
• Overridable common modules for partner settlements — customizing the algorithm for building the stage-based payment calendar.
• Access restriction (RLS) — when segregating schedules by organization/department.

Requires verification in the specific 3.4.5.21 release: the exact names of the stage tabular section attributes (ЭтапыОплаты/Этапы, Процент/ДоляПлатежа, КоличествоДней/СрокОплаты) and the composition of the ВариантыОплаты enumeration — these are version-dependent details that should be verified in the configurator.