1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | EmailFolders |
| Full Name | Catalog.EmailFolders / Catalogs.EmailFolders |
| Synonym | — (matches the name: “Email Folders”) |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Hierarchy | Hierarchical (hierarchy of groups and items — nested folders) |
| Owner (Subordination) | Email account |
| Purpose | Organization of a hierarchical structure for storing emails in the built-in 1C email client. Grouping incoming, outgoing, and other categories of emails into folders similar to the structure of a regular email client. Supports predefined system folders (Inbox, Sent, Deleted, etc.) and user folders. Correspondence segregation between users is ensured through the owner — the email account. |
The catalog relates to the "Working with Emails" mechanism of the standard subsystem library (BSP) and is an infrastructural (service) object. It does not participate in accounting and tax accounting, does not generate postings and movements in accounting registers — this should be taken into account when reading section 5.
Where to find in 1C:
- Navigation link:
e1cib/list/Catalog.EmailFolders - In the interface: section “Standard Subsystems” → “Email Folders” (usually opened from the email client form when working with correspondence).
2. Attributes of Header and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| PredefinedFolder | Boolean (xs:boolean) |
Not checked (DontCheck) | Indicates a system predefined folder (Inbox, Sent, etc.). Protects the folder from accidental deletion and modification of key parameters. Automatically set when creating system folders. |
| TypeOfPredefinedFolder | Enumeration.TypesOfPredefinedEmailFolders |
Not checked (DontCheck) | Classifies the purpose of the predefined folder (inbox, outgoing, drafts, deleted, spam, etc.). Used by the system for automatic routing of emails to the corresponding folder. Filled only for predefined folders. |
2.2 Standard Attributes
In addition to its own attributes, the catalog uses standard attributes of the platform:
| Attribute | Role in Object |
|---|---|
| Code | Internal identifier of the catalog item. |
| Name | Displayed name of the folder (e.g., “Inbox”, “Projects”, “Client A”). |
| Parent | Implements hierarchy — container folder for nested folders. |
| Owner | Email account to which the folder belongs. Ensures visibility segregation of correspondence between users/boxes. |
| DeletionMark | Indicates a mark for deletion (for non-predefined folders). |
2.3 Table Parts
Table parts are absent.
3. Forms
| Form | Purpose |
|---|---|
| ListForm | Main form for the list of folders: viewing hierarchy, navigation through nested folders, creating/renaming user folders. |
| ElementForm | Form for editing a single folder — key for creation and modification. Here, the name, parent, and owner are set; for predefined folders, key fields are protected from modification. |
| SelectionForm | Form for selecting a folder when assigning an email to a specific folder (moving the email, selecting the target folder). |
4. Key Module Procedures
Evidence with the text of BSL modules for this object is not attached, so below are typical handlers for the service catalog BSP “Email Folders”. Specific names/lines should be clarified in the specific release.
Object Module (ObjectModule):
BeforeWriting— control of the correctness of modifying predefined folders: as a rule, prohibition of changing the attributesPredefinedFolderandTypeOfPredefinedFolderfor system folders, checking the consistency of the hierarchy (a folder cannot be made subordinate to itself / its nested folder).BeforeDeleting— blocking the deletion of predefined folders (a folder withPredefinedFolder = Truecannot be deleted).ProcessingFilling— filling in the owner and default attributes during interactive creation.
Element Form Module (ElementForm):
OnCreateOnServer— setting the availability of attributes: for predefined folders, the name/type fields are blocked, and the indication of a system folder is displayed.OnReadOnServer— additional adjustment of visibility depending on the folder type.
Manager Module / Common Email Handling Modules (BSP, subsystem “Working with Emails”):
- Functions for obtaining a predefined folder by type (
TypesOfPredefinedEmailFolders), creating missing system folders for the account, determining the receiving folder for incoming/outgoing emails during mailbox synchronization.
Requires verification (version-specific): exact names of procedures and distribution of logic between the object module and common BSP modules depend on the version of the standard subsystem library included in 3.0.74.2.
5. Postings and Movements
The catalog is not a document and is not posted: it does not generate accounting postings and does not create movements in accounting/tax registers. It is a classifier for organizing the storage of emails.
Accordingly, for this object the following are not applicable:
- postings according to the standard chart of accounts of the RK (1210 “Short-term receivables from customers”, 1030 “Cash in current accounts”, 1330 “Goods”, 3310 “Payables to suppliers”, 3130 “VAT payable”, 6010 “Revenue from sales”, 7010 “Cost of sales”);
- calculations for taxes and contributions of the RK (VAT 16%, PIT 10% up to 8,500 MRP annual income and 15% above, OPE 10% with a base cap of 50 MZP, OPR 3.5%, VOSMS 2%, OSMS 3%, CO 5%, social tax 6%; basic deduction for PIT 30 MRP/month, not more than 360 MRP per year; MRP = 4,325 ₸, MZP = 85,000 ₸);
- formation of electronic documents (ESF in IS ESF, CNT).
The only “movements” of the object are changes to its own record in the catalog table (creation/renaming/moving the folder in the hierarchy) and linking with emails through the email attribute indicating the folder. The above numerical norms of the RK for 2026 are provided for reference for the uniformity of configuration materials and do not directly relate to this object.
6. Related Objects and Input on Basis
| Relation | Object | Nature of Relation |
|---|---|---|
| Owner | Email account | Each folder belongs to a specific account; when the account is deleted, its folders become irrelevant. |
| Classifier of Types | Enumeration.TypesOfPredefinedEmailFolders |
Defines the purpose of predefined folders and rules for automatic routing. |
| Stored Emails | Objects for storing emails (incoming/outgoing emails BSP) | Emails refer to the folder; the folder acts as a container. Moving an email = changing the reference to the folder. |
| Hierarchy | The catalog itself (Parent) |
Nested folders. |
Input on Basis: not provided and does not make sense for this type of object. Creation of elements is performed interactively from list/selection forms or programmatically during the initialization of the email account (auto-creation of predefined folders).
7. Extension Points
- Configuration Extension (form adapters): adding form attributes or columns in
ListForm/ElementForm, for example, user labels/color highlighting of folders, without removing the object from support. - Additional Attributes and Information: if the catalog has the “Properties” subsystem enabled, additional attributes/information can be added (e.g., indication of an archive folder) without changing metadata.
- Event Subscriptions (
BeforeWriting,BeforeDeleting): control of user naming rules, automatic assignment of the owner, auditing changes in folder structure. - Overridable Common BSP Modules of the “Working with Emails” subsystem: configuration of the list and logic for creating predefined folders, rules for routing emails.
- Roles and RLS: additional access restriction to folders by owner (account) to segregate correspondence between users.
When making any modifications, maintain the protection of predefined folders (do not allow changes to
PredefinedFolder/TypeOfPredefinedFolderand deletion of system folders) — this is essential for the correct operation of the email client.