1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | ServiceCatalog |
| Full Name | Catalogs.ServiceCatalog / Catalog.ServiceCatalog |
| Synonym | — (not specified) |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Object View | Reference catalog of the "Service Technology" subsystem |
Purpose. The catalog stores a list of services provided within the 1C service model. It serves for the classification and management of types of services that are included in tariff plans or provided separately. This is a service object of the configuration: it works in conjunction with the billing and tariffing mechanisms and is not an accounting (primary) document. It is used by system administrators and technical support specialists when setting up tariffs, connecting new services, and changing parameters of existing services.
Where to find in 1C: section "Service Technology" → "Service Catalog".
Navigation link: e1cib/list/Catalog.ServiceCatalog
2. Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Identifier | String (xs:string) |
Mandatory (ShowError) | Unique identifier of the service in the system. Used for programmatic identification and integration with external systems. A key field for technical work with the service. |
| ShowWhenAddingToTariff | Boolean (xs:boolean) |
Optional (DontCheck) | Flag for displaying the service in the interface when forming/editing tariff plans. Allows hiding service or outdated services from users. |
| ServiceProvider | ReferenceLink.ServiceProviders | Mandatory (ShowError) | Link to the organization/department providing the service. Necessary for correct accounting and routing of service requests. |
| Billable | Boolean (xs:boolean) |
Optional (DontCheck) | Indicates that the service is subject to billing and accounting in the billing system. If the flag is off, the service may be free or provided without consumption accounting. |
| ServiceType | EnumerationLink.ServiceTypes | Mandatory (ShowError) | Classifier of the service by functional purpose. Determines the category, may influence the logic of processing, billing, and display in interfaces. |
In addition to the listed, the object inherits standard fields of the catalog: Code, Name, DeletionMark, Predefined, as well as hierarchy attributes if included.
2.2 Table Parts
Table parts are absent.
3. Forms
In the object's metadata, custom forms are not defined — the catalog uses standard automatically generated forms of the platform:
| Form | Purpose |
|---|---|
| Element Form (auto) | View and edit the service card: filling in Identifier, ServiceProvider, ServiceType, flags Billable and ShowWhenAddingToTariff. |
| List Form (auto) | View the list of services, filtering/searching, marking for deletion, entering new items. |
| Selection Form (auto) | Selecting a service in other objects (for example, when setting up tariff plans). |
4. Key Module Procedures
Evidence with the text of modules (BSL) for this object is not attached, so below is a typical set of handlers for a catalog of this type. Availability and exact implementation depend on the version of the configuration.
Object Module (FillingHandler, BeforeSaving, OnCopying):
FillingCheckHandler— control of mandatory attributesIdentifier,ServiceProvider,ServiceType(set by the ShowError flag at the metadata level, processed automatically; if necessary, supplemented by programmatic uniqueness check ofIdentifier).BeforeSaving— normalization of the valueIdentifier, checking for duplicates before fixing.FillingHandler— setting default values (for example,Billable = True) during interactive creation.
Element Form Module:
OnServerCreation/OnOpening— setting the availability of fields depending on the flagBillable.BillableOnChange— managing visibility/accessibility of elements related to billing in the form.
Manager Module: typical procedures for selecting/getting services for programmatic access (integration, tariff formation).
Requires verification: specific names and content of the object/form module procedures are version-specific and should be checked against the delivery code 3.0.74.2.
5. Posting and Movements
The catalog is not posted and does not generate movements in registers/postings — this is a property of catalogs as a class of objects. ServiceCatalog only stores regulatory and reference information.
Impact on accounting — indirect: a billable service (Billable = True) enters documents of realization/billing through the tariff plan, and these documents generate postings. According to the typical Chart of Accounts of the RK and the norms of the RK 2026, the standard scheme for service realization looks like this:
| Operation | Debit | Credit | Comment |
|---|---|---|---|
| Income from service accrued | 1210 (short-term receivables from customers) | 6010 (income from sales) | For the amount excluding VAT |
| VAT accrued | 1210 | 3130 (VAT payable) | VAT rate 16% |
| Payment received | 1030 (cash in current accounts) | 1210 | Closing receivables |
Example: service for 100,000 ₸ excluding VAT → VAT 16,000 ₸ (16%), to be received 116,000 ₸. Debit 1210 Credit 6010 — 100,000 ₸; Debit 1210 Credit 3130 — 16,000 ₸.
For realization, electronic documents of the RK are issued: ESF (via the ESF IS) and, if necessary, SCT. Currency of calculations — tenge (₸).
6. Related Objects and Input on Basis
- Reference.ServiceProviders — source of the value for the attribute
ServiceProvider. - Enumeration.ServiceTypes — classifier for the attribute
ServiceType. - Tariff plans (tariffing subsystem) — consumer of the catalog; services with the flag
ShowWhenAddingToTariff = Trueare available when forming tariffs, with the flagBillable— accounted in billing. - Realization/billing documents — use services when forming accruals and postings (see section 5).
Input on basis: for a service catalog, the mechanism of "input on basis" is generally not provided; items are created manually in the list or programmatically during integration.
7. Extension Points
- External configuration extension: adding attributes (for example, billing unit, validity period), custom element/list forms, additional handlers
BeforeSaving/FillingCheckHandler. - Additional attributes and information (general mechanism) — for extending service properties without changing metadata.
- Event subscriptions (
BeforeSaving,OnSaving) for integration synchronization ofIdentifierwith external systems. - Manager programming interface — point for procedures for selecting/filtering services during integration and tariff formation.
It is not recommended to modify standard metadata directly — use extensions to maintain the ability to update the configuration.