Report "FulfillmentOfConditionsOfAgreementsWithClients" (UT for Kazakhstan 3.4)

1. Identification

Purpose. The report is designed to monitor the fulfillment of regular (periodic) terms recorded in customer agreements. Regular terms refer to obligations of the parties checked at a set frequency (month, quarter, etc.): planned purchase volume, minimum shipment amount for the period, maintaining an assortment, compliance with a payment schedule, the customer's reciprocal obligations (merchandising, product placement, etc.). The report compares the planned terms of the agreement with the actual sales/payment figures for the selected period and shows the degree of fulfillment, deviation, and status (fulfilled / not fulfilled / partially fulfilled). This is a tool for the sales manager and department head to analyze discipline in fulfilling agreements and to make decisions on granting/revoking bonuses and discounts tied to the agreement.

2. Parameters, Fields, and Report Structure

The report is built on the DCS, so instead of document header/tabular section attributes, it operates with scheme parameters, dataset fields, and variant settings (groupings, filters, indicators). Below is a typical composition.

2.1. Composition Parameters (Report Form Header)

2.2. Dataset Fields (Analytics and Resources)

Monetary resources are displayed in tenge. Sales amounts are taken accounting for the VAT rate of 16% in effect in Kazakhstan; if needed, the report can show indicators both with and without VAT — depending on the agreement term's settings.

3. Forms

For a DCS-based report, the typical set of forms is minimal:

The report has no separate list/item forms — it is neither a catalog nor a document.

4. Key Module Procedures

The attached evidence contains only the purpose facet (naznachenie); the module source code (BSL) is not attached. Therefore, below is a typical set of handlers for a DCS-based report in Trade Management; specify exact lines upon access to the configurator.

Report object module (ОтчетОбъект):

• ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) — output interception: programmatic generation or fine-tuning of composition (external calculation of fulfillment percentage, status highlighting, substitution of norms from the agreement).
• ПриОпределенииИспользуемыхТаблиц(...) / ПриОпределенииНастроекОтчета(...) — integration with the SSL "Report Variants" subsystem: description of variants, available fields, formatting.

Report form module (ФормаОтчета):

• ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) — setting default parameter values (period, organization, agreement filter from the opening context).
• ПриКомпоновкеРезультатаНаСервере — fine-tuning before output.
• Panel command handlers ("Generate," variant switching).

Common DCS/scheme modules: the dataset query accesses sales and settlement registers, while term norms are drawn from the attributes and tabular sections of the agreements catalog.

Requires verification (version-specific): the exact composition of program handlers and the presence of a custom report form may differ in build 3.4.5.21 — to be clarified via the configurator.

5. Data Sources and Movements

The report is not a document and does not perform posting — it does not generate journal entries or create register movements. Its role is the opposite: it reads already generated data. Key sources:

• Sales accumulation registers (Продажи, ВыручкаИСебестоимостьПродаж, and related) — for the fact of shipments and revenue by customer/agreement.
• Customer settlement registers (РасчетыСКлиентами, ЗадолженностьКлиентов) — for the fact of payments when monitoring payment terms.
• Catalog СоглашенияСКлиентами and its tabular sections — for planned norms of regular terms.

For understanding which journal entries generate the facts read by the report (standard implementation logic in Kazakhstan), a reference block is provided for a typical Kazakhstan chart of accounts:

Sales in Kazakhstan are accompanied by the issuance of an ESF (electronic invoice, ESF IS) and, for goods movement, a SNT (goods consignment note). The agreement terms report does not issue these documents but relies on the sales fact they accompany.

The VAT rate applied to sales amounts is 16% (Kazakhstan 2026 norm). Agreement term indicators (planned amounts, thresholds) are set in tenge.

6. Related Objects and Entry Based On

• Справочник.СоглашенияСКлиентами — source of planned terms; the main related object. The report is usually opened from the agreement card via a navigate-to-report command.
• Справочник.Партнеры / Справочник.Контрагенты — parties to the agreement.
• Sales documents (РеализацияТоваровУслуг, etc.) and payment documents — sources of actual data.
• "Report Variants" mechanism (SSL) — storage of custom settings and variants.

Entry based on is not applicable to the report — reports do not participate in entry-based-on chains (that is the prerogative of documents). A reverse scenario is possible through application logic: based on the analysis results, the manager manually initiates the accrual of a bonus/discount, but this is not the report's "entry based on" mechanism.

7. Extension Points

• Custom report variants — saving groupings, filters, conditional formatting (by fulfillment status) without modifying the configuration.
• Configuration extension: adding custom datasets/fields to the composition schema, intercepting ПриКомпоновкеРезультата for non-standard calculation of the fulfillment percentage or blending in reciprocal obligations.
• Agreements catalog enhancement: introducing new types of regular terms is reflected in the report with a corresponding extension of the schema query.
• Additional filters and functional options — integration with Kazakhstan's regional specifics (tenge currency, 16% VAT rate) through scheme parameters.
• Access rights (RLS) — visibility restriction by organization/manager is inherited from configuration roles.