--- title: "Types of Deals with Clients\" Directory (Trade Management for Kazakhstan 3.4)" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-24 canonical: https://buhgpt.kz/suraqtar/spravochnik-vidysdeloksklientami-upravlenie-torgovley-dly-en source: BuhGPT --- # Types of Deals with Clients" Directory (Trade Management for Kazakhstan 3.4) > **TL;DR:** 1. Identification Parameter Value Object type Catalog Name ВидыСделокСКлиентами Full name Справочник.ВидыСделокСКлиентами ( Catalogs.ВидыСделокСКлиентами ) Synonym "Types of Deals with Customers" Configuration Trade Management for Kazakhstan, edition 3.4 (version 3.4.5.21) Sub --- 1. Identification Parameter Value Object type Catalog Name ВидыСделокСКлиентами Full name Справочник.ВидыСделокСКлиентами (Catalogs.ВидыСделокСКлиентами) Synonym "Types of Deals with Customers" Configuration Trade Management for Kazakhstan, edition 3.4 (version 3.4.5.21) Subsystem Service subsystems Where to find in 1C Section "Service subsystems" → "Types of Deals with Customers". Navigation link: e1cib/list/Справочник.ВидыСделокСКлиентами Purpose. A classifier catalog that defines the list of types of deals concluded with customers. Element values are used as an analytical attribute in interaction and sales documents (customer deals, commercial proposals, orders), as well as a dimension in reports on the sales funnel, manager performance, and reasons for winning/losing deals. The object itself is a reference/regulatory one: it does not store amount indicators and is not directly involved in tax calculation — it only classifies deals, whose financial consequences are reflected in sales documents. Note: the catalog is a service (setup) one. Its elements are generally filled in during initial setup and rarely change during operation. 2. Header attributes and tabular sections No evidence on the composition of attributes has been provided. Below is the typical composition of a classifier catalog of this kind; the specific set of attributes should be verified in the Configurator for version 3.4.5.21. Standard attributes (predefined by the platform): Attribute Type Purpose Код String/Number Unique element code, auto-numbering Наименование String (usually 150) Representation of the deal type in lists and selection ПометкаУдаления Boolean Deletion mark flag Предопределённый Boolean Predefined element flag (if defined) Typical header attributes: Attribute Type Purpose Наименование String Name of the deal type (e.g., "Initial sale", "Repeat sale", "Renewal", "Project deal") Комментарий / Описание String (unlimited) Free-form explanation of the deal type Порядок / ИндексКартинки Number Display order / visual attribute (if present) Tabular sections. A classifier catalog of this purpose typically has no tabular sections. If a specific build contains a "AdditionalAttributes"/"AdditionalInformation" tabular section, it is provided by the "Properties" subsystem of the SSL (Standard Subsystems Library), not by the object's own fields. 3. Forms As a rule, for a service classifier catalog, forms are generated automatically or defined in minimal composition: Form Purpose List form (ФормаСписка) Viewing and maintaining the list of deal types, marking for deletion, search/filtering Item form (ФормаЭлемента) Creating/editing a single deal type (name, description) Selection form (ФормаВыбора) Selecting a value when filling in the "Deal Type" attribute in documents Custom managed forms may not be defined (auto-generated ones are used). The presence of explicitly defined forms should be verified in the Configurator for version 3.4.5.21. 4. Key module procedures No evidence with BSL code has been provided. A classifier catalog without specific business logic is typically characterized by a minimal set of handlers (or their absence). Typical points that may be implemented: - Object module → ОбработкаЗаполнения — initial filling of attributes when entering a new element (including based on another object). - Object module → ПередЗаписью / ПриУстановкеНовогоКода — correctness control and filling of service fields. - Manager module → ОбработкаПолученияФормы — form substitution for special scenarios (usually not required). - Item form → ПриСозданииНаСервере, ПриЧтенииНаСервере — configuring field availability, connecting the SSL "Properties" subsystem. - List form → ПриСозданииНаСервере — configuring conditional formatting and filters. The presence and content of the listed procedures is version-dependent — to be verified in the object modules for build 3.4.5.21. 5. Posting and movements The catalog is not a document and is not posted — it does not generate its own register movements. Its role in accounting is an analytical dimension of the deal, whose financial result is reflected by related sales documents. Below is shown how this dimension participates in the standard sales chain according to the Kazakhstan chart of accounts (with 2026 Kazakhstan parameters). Typical entries for sale of goods to which the deal type is linked: Operation Dr Cr Comment Sales revenue recognized 1210 6010 Short-term receivables from customers / sales revenue VAT accrued 1210 3130 VAT payable at the rate of 16% (Kazakhstan 2026 rate) Cost of sales written off 7010 1330 Cost of sales / goods Payment received 1030 1210 Cash in current accounts / receivables settlement Example: sale for 1,160,000 ₸ with 16% VAT → revenue 1,000,000 ₸ (Dr 1210 Cr 6010), VAT 160,000 ₸ (Dr 1210 Cr 3130); upon receipt of payment — Dr 1030 Cr 1210 for 1,160,000 ₸. Registers where the catalog value serves as a dimension/analytical attribute: information and accumulation registers of the CRM/sales subsystem (deals, deal statuses, sales funnel). The specific list of registers with the "Deal Type" dimension should be verified within the subsystem for version 3.4.5.21. Electronic documents. The catalog itself is not uploaded to the ESF (ESF Information System) or SNT. It affects accounting only indirectly — through sales documents that generate the ESF/SNT. The tax consequences of the deal (VAT 16%, if applicable individual income calculations — IIT 10%/15%, MPC 10%, VOSMS 2%, social tax 6%, etc.) are determined by the documents and accounting policy settings, not by this classifier. 6. Related objects and entry based on - Documents using the deal type as an analytical attribute: CRM and sales documents — "Customer Deal", "Commercial Proposal to Customer", "Customer Order", as well as related reports (sales funnel, deal performance). - Entry based on: the classifier catalog is generally neither a basis nor an object for entry based on another document. An element is created manually from the list form or by selecting "new" from a document field. - Relationship with catalogs: used together with the "Partners"/"Counterparties", "Customer Agreements", "Users" (managers) catalogs as one of the dimensions for deal analysis. 7. Extension points - SSL "Properties" subsystem — adding additional attributes and information to deal types without changing the object's metadata. - Configuration extension — adding custom attributes, forms, and handlers (ПередЗаписью, ПриСозданииНаСервере) without removing the standard configuration from support. - Event subscriptions — processing the writing/deletion of catalog elements for integrations and logging. - Additional reports and data processors — external reports by the "Deal Type" dimension (sales analytics). - Predefined elements — if hard-coded logic tied to a specific deal type is required, predefined values are defined (verify their presence in version 3.4.5.21). Recommendation: extend behavior through SSL mechanisms and configuration extensions to keep the standard configuration on support during 3.4.x updates. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_