1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | IntegrationSettingsWebKassa |
| Full Name | Catalog.IntegrationSettingsWebKassa |
| Alias | Integration settings 1C:WebKassa |
| Configuration | Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) |
| Purpose | Storage of connection parameters to the fiscalization service WebKassa — the Kazakh system for online transmission of fiscal receipts (data from cash registers) to the state revenue authorities (GRA of the Ministry of Finance of the RK). |
The catalog stores integration parameters with WebKassa by organization. Each element is linked to one organization and contains the address of the fiscal service and a list of usernames from the information base through which the system makes requests to the fiscal operator.
Key Feature: only one active (not marked for deletion) integration setting is allowed for one organization. This ensures the unambiguity of parameter selection during fiscalization.
Where to find in 1C: section “Integration 1C:WebKassa” → “Integration settings 1C:WebKassa”.
Navigation link: e1cib/list/Catalog.IntegrationSettingsWebKassa
2. Header Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Organization | CatalogReference.Organizations | ShowError (mandatory) | The organization for which the integration with WebKassa is configured. The key uniqueness field of the setting — it determines whose connection parameters to apply during fiscalization. |
| ServiceAddress | String (xs:string) | ShowError (mandatory) | The URL address of the WebKassa service that the system accesses for fiscalizing documents. Used when forming HTTP requests to the fiscal operator. |
Standard fields are inherited from the catalog mechanism: Code, Name, DeletionMark, Predefined, Reference.
2.2 Table Parts
Users — a list of users who have access to work with WebKassa for this organization.
| Name | Type | Purpose |
|---|---|---|
| Username | String (xs:string) | The username from the information base that is allowed to perform fiscalization operations through the configured service. Used to delineate access rights to the integration. |
3. Forms
In the configuration, custom forms for the object are not defined (the forms array is empty). The platform uses auto-generated forms:
| Form | Purpose |
|---|---|
| Element form (auto) | Input/editing of settings: selecting an organization, entering the service address, filling in the users table. |
| List form (auto) | Viewing the list of settings for all organizations, filtering, marking for deletion. |
| Selection form (auto) | Selecting an element during programmatic/interactive selection of settings. |
If customization is needed (for example, a “Check Connection” button), the element form should be explicitly created — see section 7.
4. Key Module Procedures
Evidence with the text of BSL modules is not attached, so below are the typical handlers of this type of object, implementing the described business logic (uniqueness of settings per organization).
| Handler | Module | What it does (typical logic) |
|---|---|---|
CheckFillingHandler |
Object module | Checks the filling of mandatory Organization and ServiceAddress; if necessary — the correctness of the URL and the non-emptiness of the Users table. |
BeforeWriting |
Object module | Uniqueness control: checks the absence of another non-marked for deletion element with the same organization by querying the catalog; if violated — Refusal = True and a message to the user. |
FillingHandler |
Object module | Filling in default values (for example, organization from the current user's settings). |
ServiceAddressOnChange |
Element form (when explicit form) | Normalization of the entered URL (trimming spaces, checking http/https scheme). |
Functions for accessing the service (forming HTTP requests, authorization, sending receipts) in the typical configuration are moved to common modules of the WebKassa integration subsystem, not in the module of the catalog itself: the catalog serves as a source of connection parameters.
5. Posting and Movements
The catalog is not a document and is not posted. It does not generate records in accounting registers and accumulation registers, and does not create accounting entries.
The economic result of fiscalization (sales through cash registers) is reflected in related documents of the configuration that use this catalog as a source of parameters. According to the standard accounting logic in the RK, entries are formed (typical chart of accounts of the RK, VAT rate 16%, currency — tenge ₸):
| Operation | Dr | Cr |
|---|---|---|
| Recognition of revenue from sales | 1210 “Short-term receivables from buyers” / 1030 “Cash in current accounts” | 6010 “Revenue from sales” |
| Accrual of VAT (16%) | 1210 / 1030 | 3130 “VAT payable” |
| Write-off of the cost of goods | 7010 “Cost of sales” | 1330 “Goods” |
Example: sale for 116,000 ₸ including VAT → revenue 100,000 ₸ (Cr 6010), VAT 16,000 ₸ (Cr 3130). The fiscal receipt is sent to WebKassa based on the parameters from the catalog.
Electronic documents accompanying the turnover: ESF (ESF IS) and SNT — are issued as separate configuration objects and are not directly related to the WebKassa settings.
6. Related Objects and Input Based On
- Catalog.Organizations — owner of the parameters (attribute
Organization). - Users of the Information Base — the
Userstable refers to the usernames from the information base. - Fiscalization Documents (cash register receipts / retail sales reports) — consumers of the settings: when processing a receipt, the system finds the active setting by the organization of the document and accesses WebKassa via its
ServiceAddress. - Common modules of the “Integration 1C:WebKassa” subsystem — use the catalog element as a source of URL and access list.
Input based on for this catalog is not provided by standard mechanisms (this is a settings object, not a primary document).
7. Extension Points
- Connection check. Add a custom element form with a command that triggers a test HTTP request to
ServiceAddressand displays the result. - Storage of tokens/secrets. Logins/passwords or API keys for WebKassa should not be stored in an open attribute, but in a secure storage (
CommonSettingsStorage/ register with access restriction); theUserstable only specifies the list of names. - Subscription to events
BeforeWriting/CheckFillingHandler— for additional control of uniqueness and URL validation without changing the object module. - Configuration extension — a safe way to add attributes (for example, cash register IIN/BIN, cash register number, shift number) and logic without removing the typical configuration from support.
Requires verification for a specific build: the exact composition of common modules of the integration subsystem and the presence of predefined uniqueness control in
BeforeWriting— they are version-dependent and may differ in different releases 3.0.7x.