1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | EmailProcessingRules |
| Full Name | Catalog.EmailProcessingRules |
| Synonym | Email processing rules |
| Configuration | Accounting for Kazakhstan, edition 3.0 (3.0.74.2) |
| Subsystem | Standard subsystems → Email handling / Interactions |
Purpose. The catalog is designed to automate the processing of incoming emails in the interaction subsystem of 1C. Each element stores a set of conditions for filtering emails (by sender, subject, date, and other criteria) and the target folder to which emails that meet the conditions are moved. The rules are applied automatically upon receiving new correspondence or can be manually triggered to process already accumulated emails. It is used by employees and managers dealing with a large volume of correspondence for sorting and routing.
This is a service catalog of the interaction subsystem — it does not relate to accounting (tax/accounting) objects, does not participate in the calculation of VAT, individual income tax, social tax, etc., and does not affect regulated accounting.
Where to find in 1C: section "Standard subsystems" → "Email processing rules".
Navigation link: e1cib/list/Catalog.EmailProcessingRules
2. Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
SettingsCompiler |
Value storage | No (DontCheck) | Contains settings of the data composition system (DCS) for filtering emails by various criteria (sender, subject, date, etc.). Key attribute: defines the conditions for applying the rule. |
PlaceInFolder |
CatalogReference.EmailFolders | Yes (ShowError) | The target folder to which emails that meet the rule's conditions are moved. Mandatory upon recording. |
AdditionalSortingAttribute |
Number (xs:decimal) | No (DontCheck) | Defines the order of applying rules: rules with a lower value are applied first. Used for sorting the list. |
SelectionRepresentation |
String | No (DontCheck) | Text representation of the configured selection conditions for display in the interface. Formed automatically based on the settings of the compiler. |
In addition to the listed attributes, the element has standard catalog attributes: Code, Name, DeletionMark, Reference, Predefined.
2.2 Table Parts
Table parts are absent. All selection conditions are stored within SettingsCompiler (DCS), not in a separate table part.
3. Forms
| Form | Type | Purpose |
|---|---|---|
ListForm |
List form | List of rules with the command to apply rules; mass operations and sorting of rules are initiated from here. |
ElementForm |
Element form | Editing a single rule: configuring the selection compiler, choosing the target folder, order of application. Key configuration form. |
ApplyRules |
Service form | Specialized form for mass application of rules to already existing emails in folders (batch processing). |
4. Key Module Procedures
The attached evidence does not provide the text of the modules (BSL), so below are typical handlers for a catalog of this type. Specific signatures and lines should be verified with the module of the specific assembly.
Object Module (CheckFilling)
- Check filling of
PlaceInFolder(the attribute is marked ShowError — recording is blocked if the value is empty).
Object Module (BeforeWriting / OnWriting)
- Recount and record
SelectionRepresentationfrom the settings of the compiler, so that the text representation corresponds to the actual conditions.
Element Form Module
OnCreationOnServer— initialization of the settings compiler, restoration of settings fromSettingsCompiler, loading available selection fields (sender address, subject, date, presence of attachments, etc.).BeforeWritingOnServer— saving current DCS settings in the attributeSettingsCompiler, formingSelectionRepresentation.
List Form / "ApplyRules" Form Module
- Command "Apply rules" — iterating through selected emails (or all emails in the specified folder), checking each email for compliance with DCS conditions in ascending order of
AdditionalSortingAttributeand moving matching emails toPlaceInFolder.
The logic of checking email compliance with the conditions is executed through the data composition mechanism (building selection from SettingsCompiler and applying it to the email data).
5. Posting and Movements
The catalog is not posted and does not generate movements in accounting registers, accumulation, or information. An object of type "Catalog" has no posting by definition.
The only "effect" of applying the rule is the change of the folder attribute for objects in the interaction subsystem (moving the email to the folder PlaceInFolder). This catalog does not generate any accounting entries.
For comparison: accounting documents of the configuration generate entries according to the standard chart of accounts of the RK (for example, sale — Debit 1210 Credit 6010 for the amount of income, Debit 1210 Credit 3130 for VAT at a rate of 16%, Debit 7010 Credit 1330 for cost; payment from the buyer — Debit 1030 Credit 1210; receipt of goods — Debit 1330 Credit 3310). The catalog of email processing rules has no relation to this logic and is presented here only for contrast.
6. Related Objects and Input Based On
| Relation | Object | Nature of Relation |
|---|---|---|
| Target Folder | Catalog.EmailFolders |
The attribute PlaceInFolder refers to the placement folder. |
| Processed Data | Documents/objects of the interaction subsystem ("Incoming email", "Interaction") | The rule analyzes and moves these emails. |
| Email Accounts | Catalog.EmailAccounts |
The rules apply to emails received through configured email accounts. |
Input Based On. Not provided: the catalog is neither a basis nor a result of input based on. Elements are created manually in the list/element form.
7. Extension Points
- Configuration Extension. Adding attributes to the element form, additional processing commands, overriding handlers
BeforeWriting/OnWritingthrough borrowing forms and the object module. - Additional Selection Fields. Extending the set of fields in the compiler (for example, filtering by sender domain, by the presence of certain attachments) through modifying the DCS scheme used when initializing the form.
- Programmatic Creation/Application of Rules. Through the object model: creating an element, filling
SettingsCompilerandPlaceInFolder, calling the application algorithm to the selection of emails. - Additional Handlers (BSL). The mechanisms "Additional reports and processing" and event subscriptions can be used for non-standard routing of emails without changing the catalog itself.
- Access Control. Configuring rights through RLS/roles of the interaction subsystem if it is necessary to restrict the visibility of rules among users.
Requires verification for the specific assembly: the exact composition of forms and the presence/names of service handlers of the object module may differ between BSL releases — verify with the module in the configurator version 3.0.74.2.