Directory "Retail Tax Rates" — Technical Description (Accounting for Kazakhstan 3.0.74.2)

Directory «RetailTaxRates»

Configuration: Accounting for Kazakhstan, edition 3.0.74.2. All numerical norms — for the RK in 2026 (MPR = 4,325 ₸, MZP = 85,000 ₸, VAT rate = 16 %).

The retail tax in the RK is a special taxation regime under which certain types of activities are taxed at a reduced turnover tax rate instead of corporate income tax (CIT)/individual income tax (IIT) and VAT. This directory maintains a list of applicable percentage rates and serves as a source of the rate value for sales documents and accounting policy settings.

1. Identification

Purpose. Storage and maintenance of retail tax rates applied when processing retail sales in the RK. The directory is an element of regulatory and reference information (NRI): it does not generate its own movements and entries, but serves as a source of the rate value for calculating tax liabilities in documents and settings. Access to the directory is episodic — during initial accounting setup or changes in legislation (for example, when adjusting tax rates for the period).

Where to find in 1C: tax accounting settings section → “Retail tax rates”; or through universal search/navigation link e1cib/list/Directory.RetailTaxRates.

2. Attributes and table parts

2.1 Header attributes

In addition to the explicitly declared attribute, the directory as a standard metadata object has builtin (standard) attributes:

• Name — string, the main representation of the element in lists and selection fields;
• Code — string or number, unique identifier of the element within the directory;
• Parent — reference, supporting hierarchy;
• ThisIsGroup — boolean, group indicator for hierarchical directories;
• Reference, DeletionMark, Predefined — service.

2.2 Table parts

None. The directory has a flat structure: each element carries a single significant value — the numerical tax rate.

2.3 Practical filling

The element stores the retail tax rate (for example, a reduced retail tax rate is applied for retail trade in the RK). The value of the Rate field is the percentage that is multiplied by the turnover when calculating the liability. Note: the retail tax rate is not equal to the VAT rate (16 % for 2026) — these are different taxes; VAT is not stored in the directory.

3. Forms

The directory contains three standard forms:

4. Key module procedures

Application BSL code in evidence is not attached — below are listed typical handlers for a directory of this type. The presence of a specific procedure in this version should be confirmed by the object/form module.

Object module (ObjectModule):

• BeforeWriting(Refusal) — control of the correctness of the Rate value (non-negativity, range limits) before saving;
• CheckFillingProcessing(Refusal, CheckedAttributes) — checking the filling of key attributes during interactive recording;
• OnCopying(CopyingObject) — initialization of values when entering by copying.

Element form module (ElementForm):

• OnCreateOnServer(Refusal, StandardProcessing) — initial setup of the form, setting field availability;
• RateOnChange(Element) — control/formatting of the entered rate value.

List form module (ListForm):

• handlers for the command “EditSelected” for bulk modification of attributes of selected elements.

Requires verification for a specific version: the exact composition and signatures of handlers (the presence of rate range validation in BeforeWriting) — version-specific.

5. Posting and movements

The directory is not posted and does not generate independent entries/movements in registers — it is an NRI object. The rate value is used as a parameter for calculation in documents and regulatory operations.

Application scheme (according to the standard logic of the configuration and the chart of accounts of the RK):

1. When retail selling, the document calculates the tax liability as Turnover × Rate, where Rate is taken from the selected directory element.
2. The sale generates typical entries according to the national chart of accounts of the RK:

1. The retail tax is accrued at the end of the tax period through regulatory operation/declaration (entry Debit tax expense account — Credit budget settlement account); the amount is determined as turnover subject to retail tax multiplied by Rate.

The retail tax replaces CIT/IIT and VAT for the taxpayer under this special regime for the corresponding turnovers; IIT rates (10 % up to 8,500 MPR annual income, 15 % above), social payments (OPV 10 % with a base cap of 50 MZP, OPVR 3.5 %, VOSMS 2 %, OSMS 3 %, CO 5 %, social tax 6 %) and the basic deduction for IIT (30 MRP per month, but not more than 360 MRP per year) are not stored in this directory — they relate to payroll and general tax accounts.

6. Related objects and input on basis

• Organization's accounting/tax policy settings — indication of the applicable retail tax rate for the organization/type of activity.
• Retail sales documents and reports on retail sales — use the selected rate when calculating liabilities.
• Regulatory tax operations, tax declarations on retail tax — consumers of accumulated turnovers and rates for reporting formation.
• Electronic documents of the RK (ESF through IS ESF, SNT) — accompany sales; the retail tax rate participates indirectly, through the document's taxation parameters.

Input on basis for the NRI directory is generally not provided — elements are created manually in the element form. The element itself is a value object that documents and settings refer to.

7. Extension points

• Configuration extension (Extensions): adding attributes (for example, the validity period of the rate, linking to the type of activity), refining element/list forms, adding checks in BeforeWriting/CheckFillingProcessing.
• Event subscriptions of directory objects (BeforeWriting, OnWriting) — for auditing rate changes or synchronizing with external systems.
• Additional attributes and information (PVC/PVS mechanism) — if it is necessary to store arbitrary attributes without changing metadata.
• Bulk modification — standard command “EditSelected” on the list form; programmatically — through universal data processing mechanisms.

Requires verification: inclusion of the directory in specific exchange plans and the composition of synchronized data — version- and implementation-specific.