Report "Tax accounting register for income received through non-cash payments" (Accounting for Kazakhstan 3.0.74.2)

1. Object identification

Purpose. The report generates a tax accounting register for recording the income of individual entrepreneurs and organizations in Kazakhstan received in non-cash form (receipts to current/settlement accounts — account 1030). The register is used by accountants and tax specialists to prepare tax reporting and control receipts from non-cash transactions in accordance with the requirements of the Tax Code of the RK. It is generated periodically (for a month, quarter, year) to analyze the tax base and prepare declarations. It supports two modes:

• standard — a fixed register format required for submission to the state revenue authorities;
• custom — flexible configuration of groupings, filters, and additional fields for detailed analysis.

Where to find it in 1C: the “Accounting for Kazakhstan” section (subsystems) → “Tax accounting register for income received through non-cash settlements”. Direct access — via the navigation link above.

2. Settings attributes and tabular sections

As a report, the object does not store data but describes a set of generation parameters (analogous to form attributes/settings schema). Below are the register generation parameters.

2.1 Header attributes (generation parameters)

The only required attribute is Налогоплательщик (fill control ShowError). Without a specified period, the report is generated by default for the current period (set when the form is opened).

2.2 Tabular section “Grouping”

Defines the register data grouping levels (by counterparties, settlement documents, accounts, etc.).

2.3 Tabular section “AdditionalFields”

Additional columns beyond the standard register set.

3. Forms

Separate settings/variant forms are usually not distinguished — all configuration is concentrated in ФормаОтчета. Standard service forms (report variant selection, settings) are inherited from the DCS mechanism / standard report library.

4. Key module procedures

The object module and form module are not included in the evidence (BSL sources are absent). Below are typical handlers for a report of this kind in AK 3.0. Specific names/lines should be verified against the code of the version.

Report object module:

• ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) — overridable result generation: preparing the template/composer, substituting parameters (НачалоПериода, КонецПериода, Налогоплательщик), outputting to the spreadsheet document. Here the logic for the standard vs custom report type is implemented.
• ПриОпределенииИспользуемыхТаблиц, ПриОпределенииНастроек — configuring the available fields, groupings, and filters.

Form module ФормаОтчета:

• ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) — setting the default period, substituting the organization (Налогоплательщик) from user settings, initializing groupings/additional fields.
• Сформировать(Команда) → СформироватьНаСервере() — launching composition and outputting the result.
• ОбработкаРасшифровки(...) — drilling down from a register cell to the recording document (when РежимРасшифровки = Истина).
• Handlers for changes to the period, taxpayer, and grouping flags — regeneration when settings change.

Requires verification (version-specific): the exact composition of the ПриКомпоновкеРезультата procedures and the method of storing the register template (DCS schema or programmatic output) in edition 3.0.74.2.

5. Data source and records

The report is not posted and does not create records — it only reads accounting data. It cannot generate postings/register records by definition (type “Report”).

Data source. The register is built on operations of receiving funds in non-cash form and the related income. Per the typical logic of AK 3.0, the following are used:

• Accounting register “Self-supporting” — turnovers on the income and funds accounting accounts;
• registers of mutual settlements and tax accounting of individual entrepreneur income.

Accounts of the RK standard chart of accounts involved:

Example of income recognition for a non-cash receipt (sale of goods for 116,000 ₸, RK VAT 16%):

• Dr 1210 Cr 6010 — 100,000 ₸ (income excluding VAT)
• Dr 1210 Cr 3130 — 16,000 ₸ (VAT 16%)
• Dr 1030 Cr 1210 — 116,000 ₸ (non-cash payment to the current account)

The non-cash income register will include income of 100,000 ₸, confirmed by the receipt to account 1030. For an individual entrepreneur, this income is included in the calculation of the IIT tax base.

RK tax rules for 2026 (for analytics and subsequent calculation of taxes on this income):

• VAT rate — 16%;
• MCI — 4,325 ₸, MW — 85,000 ₸;
• Basic IIT tax deduction — 30 MCI per month (no more than 360 MCI per year);
• IIT — 10% up to 8,500 MCI of annual income and 15% above this threshold;
• MPC — 10% (base cap 50 MW), EPC — 3.5%, CHIF contributions — 2%, CHIF deductions — 3%, SC — 5%, social tax — 6%.

The report itself does not apply these rates — it records income. The rates are provided as context for reconciliation with declarations (IIT, form 200.00/910.00, etc.).

6. Related objects and entry based on

Entry based on is not applicable for the report (the object is not a document). Related objects:

• Catalog “Organizations” — source of the Налогоплательщик value;
• Catalog “Counterparties” — analytics for grouping by customers;
• Settlement documents (sale, receipt to account, bank statement) — recorders that are drilled down to;
• RK electronic documents: ESI (ESI IS) and CIT — primary documents on the basis of which the sale and receipt are recognized; in the income register they are used as sources of transaction confirmation;
• Chart of accounts “Standard” (RK) — accounts 1030, 1210, 6010, 3130, etc.

7. Extension points

• Configuration extension: overriding the ПриКомпоновкеРезультата procedure of the object module to change the composition/format of the register without removing it from support; adding additional fields via the ДополнительныеПоля tabular section.
• User settings: saved report variants (groupings, filters, formatting) — via the standard report variant mechanism and settings storage.
• Additional fields and groupings (Группировка, ДополнительныеПоля) — a built-in customization point without changing code: adding analytics (division, contract, item).
• Drill-down (РежимРасшифровки) — extending the drill-down handling to navigate to the required objects.
• Event subscriptions / common modules of the report library — for external control of the field composition and access rights.

Requires verification: whether the report is implemented on DCS (then it is more convenient to extend it via the data composition schema) or by programmatic output to a template — this determines the method of adding fields in edition 3.0.74.2.