Loyalty Card Types directory (Trade Management for Kazakhstan 3.4.5.21)

1. Identification

Purpose. The catalog stores the types (kinds) of loyalty cards used in the loyalty program: it defines the rules common to all cards of a given type — the card identification method (barcode, magnetic stripe, number range), the link to the discount/bonus program type, and restrictions on issuance and circulation. Specific instances of customer cards are stored separately (in the loyalty card catalog), and this catalog acts as a classifier for them. This is a settings catalog — it does not itself participate in the movement of goods and does not generate financial postings.

2. Header attributes and tabular sections

Below is the typical set of attributes of a catalog of this type in TM for Kazakhstan 3.4. The exact list can be found in Configurator: Справочник.ВидыКартЛояльности → Data.

Standard attributes

Header attributes (typical for this purpose)

Tabular sections

For a classifier catalog, tabular sections are usually absent or limited to auxiliary sets (e.g., a list of allowed sales points/registers where the card type is accepted). The presence of tabular sections must be checked against the specific build: requires verification for 3.4.5.21 — the composition of tabular sections is version-dependent.

3. Forms

If no custom form is defined for a specific purpose in the metadata, the platform uses automatically generated forms based on the attribute structure.

4. Key module procedures

There is no separate attached BSL evidence for this object, so the following describes the typical handlers for a catalog of this type (object module and form modules). See the Configurator for specific lines.

Object module (Справочник.ВидыКартЛояльности.МодульОбъекта):

• ОбработкаЗаполнения(ДанныеЗаполнения, ...) — populates default attributes when creating a new card type.
• ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты) — checks required fields (card type, identification method, correctness of the number range).
• ПередЗаписью(Отказ) — consistency checks for settings (e.g., that "Number Range From" ≤ "Number Range To", consistency of number length).

Item form module:

• ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) — configures the visibility/availability of fields depending on the card type.
• <Attribute>ПриИзменении(Элемент) — toggles the availability of related fields (e.g., when the "barcode" identification method is selected, the number length/mask setting becomes available).

List form module:

• ПриСозданииНаСервере(...) — sets filters and conditional formatting for the list.

The catalog contains no posting procedures — it is not a document.

5. Posting and register movements

The catalog is not a document and does not perform posting — it does not generate movements in accumulation/information registers and does not create accounting entries. References to the standard chart of accounts of Kazakhstan are not directly applicable here.

The influence of the card type on accounting is realized indirectly — through sales documents and loyalty mechanisms, where the card type determines the amount of the discount/bonus points awarded. To illustrate the chain, here is the standard entry scheme for sales in Kazakhstan (Kazakhstan chart of accounts, VAT rate 16% for 2026):

Discount calculation example. An item costs 10,000 ₸ with 16% VAT; the card type gives a 5% discount. Price after discount = 9,500 ₸, incl. VAT = 9,500 × 16 / 116 ≈ 1,310 ₸, revenue excl. VAT ≈ 8,190 ₸.

Bonus program registers (accrual/write-off of points) are maintained by loyalty and sales accounting documents, not by this catalog itself; the card type serves as a dimension/attribute in them.

Electronic documents (e-invoices via the e-invoice information system, waybills) are generated based on sales documents, not on the card catalog.

6. Related objects and input based on

• Loyalty cards (catalog of card instances) — each customer card refers to an item of ВидыКартЛояльности as its classifier.
• Loyalty programs / discount (bonus) card types — the card type is linked to the rules for granting discounts and accruing bonuses.
• Sales documents (sale, POS receipt / retail sale) — when a card is presented in a document, its type is used to determine the discount/bonuses.
• Loyalty information and accumulation registers — the card type serves as a dimension when storing settings and bonus movements.

Input based on. For a classifier catalog, the "Input based on" mechanism is typically not provided: items are created manually in the list or programmatically. The reverse process (creating customer cards with a specified type) is performed from the card catalog.

7. Extension points

• Configuration extension (Extensions): adding custom card type attributes, overriding/supplementing the list and item forms, connecting ОбработкаПроверкиЗаполнения, ПередЗаписью handlers via &Before/&After/&Instead annotations.
• Additional attributes and information (SSL): the catalog is typically included among the objects supporting the additional attributes/information mechanism — an extension without modifying the configuration.
• Event subscriptions: handling ПередЗаписью/ПриЗаписи via subscription for integration scenarios (exporting card types to external loyalty systems).
• External data processors and API: populating and synchronizing the catalog via HTTP/web services when integrating with CRM/acquiring systems.

Requires verification for 3.4.5.21: the exact composition of attributes, the presence of tabular sections, and the specific set of forms — verify against the Configurator of this build, as these elements are version-dependent.