1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | FileStorageVolumes |
| Full Identifier | Catalog.FileStorageVolumes (Catalogs.FileStorageVolumes) |
| Synonym | File storage volumes |
| Configuration | Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) |
| Hierarchy | None (flat list) |
| Owners | No (independent catalog) |
| Main Representation | By name |
Purpose. The catalog manages physical locations for storing files and attached documents in the configuration. It allows configuring multiple network directories (volumes) for distributed storage by specifying paths separately for Windows and Linux servers, setting the order of volume filling, and limits on their size. The catalog is filled by the administrator during the initial setup of the file storage or when expanding disk space and is then automatically utilized by the platform when users save files (when file storage is configured "in volumes on disk," rather than in the information base).
Where to find in 1C: section "Administration" → "File Storage Volumes".
Navigation link: e1cib/list/Catalog.FileStorageVolumes
2. Header Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Comment | String | Optional | Arbitrary text description of the volume for internal administration purposes; available for bulk editing |
| MaxSize | Number (decimal) | Optional | Limit on the volume size in megabytes (MB); used by the system to control filling and switch to the next volume when the limit is exceeded. A value of 0 is interpreted as "unlimited" |
| FullPathLinux | String | Conditionally mandatory* | Full path to the file storage directory on the Linux server (e.g., /mnt/files/volume1) |
| FullPathWindows | String | Conditionally mandatory* | Full path to the file storage directory on the Windows server (e.g., \\server\files\volume1) |
| FillingOrder | Number (decimal) | Mandatory | Sequence number for filling volumes; the system writes files first to the volume with the lower order number; must be unique for each volume |
| LastFileCleanupTime | Date and time | Optional | Service field; records the date and time of the last operation to clean up unnecessary files from the volume; automatically filled during the scheduled deletion operation |
*Conditional mandatory: at least one of the paths — Windows or Linux — must be filled in, depending on the operating system of the server on which the cluster operates.
Standard Attributes. In addition to the attributes defined by the developer, the catalog contains standard attributes: Code, Name, DeletionMark, Reference, Predefined. The name is used as a human-readable name for the volume (e.g., "Volume 1 - main").
2.2 Table Parts
Table parts are absent.
3. Forms
| Form | Purpose |
|---|---|
| ElementForm | Main form for editing the catalog item: entering Windows/Linux paths, maximum size, filling order, and comment. Key form for the administrator user |
| ListForm | Form for the list of volumes; in addition to navigation, provides functions for mass integrity checks of the storage and transferring (refilling) files between volumes |
| RemoveOrphanFilesFromVolume | Service form for removing "orphaned files" — files that are physically present in the volume directory but absent in the file accounting registers. Updates the LastFileCleanupTime attribute |
4. Key Module Procedures
The attached evidence does not include the texts of the modules (BSL), so below are described typical handlers characteristic of the service catalog of file storage volumes in configurations on BSP (Library of Standard Subsystems). Specific procedure names and line numbers require verification with the modules of this delivery.
Element Form Module (ElementForm)
OnCreateOnServer— sets the visibility of path fields depending on the server's OS type, locks editing when rights are insufficient.BeforeWritingOnServer/ filling check handler — controls that at least one of the paths (Windows/Linux) is filled and that the path is syntactically correct.- Handlers for selecting a directory for the
FullPathWindows/FullPathLinuxfields.
Object Module (ObjectModule)
FillingCheckHandler— checks the filling of the mandatoryFillingOrderand the presence of at least one path; if necessary, adds errors to the array of checked attributes.BeforeWriting— controls the uniqueness ofFillingOrder, normalizes paths (removes trailing slash), prohibits deleting the path from a volume that already contains files.
Manager Module / General File Handling Modules (BSP)
- Functions for finding a volume for writing the next file considering
FillingOrderandMaxSize. - Procedures for checking storage integrity and transferring files between volumes (called from
ListForm). - Scheduled procedure for cleaning up unnecessary files (called from the
RemoveOrphanFilesFromVolumeform), updatingLastFileCleanupTime.
5. Posting and Movements
The catalog is not a document and does not participate in posting — it does not generate accounting entries and does not create movements in the accumulation/information registers of accounting or tax accounting. Accordingly, the accounts of the standard chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010) and tax calculations (VAT 16%, PIT, WHT, OSSC/VOCC, SO, social tax 6%) do not apply to this object.
Interaction with the accounting mechanism is indirect: the catalog stores the addresses of directories where the platform physically saves files attached to accounting objects. Information about which volume a specific file is in is not stored in this catalog but in service information registers of the file handling subsystem (information about stored files and their binding to the volume). Thus, FileStorageVolumes specifies the "destination," while the accounting of the files themselves is maintained by separate service objects of the configuration.
6. Related Objects and Input Based On
- Attached files / file storages — service objects of the file handling subsystem of BSP that reference the catalog item as a place of physical placement. When the "in volumes" storage mode is turned off, the catalog is not used (files are stored in the IB).
- Information registers of the file subsystem — record the correspondence "file ↔ volume".
- Scheduled tasks — cleaning up unused files and controlling volume filling use data from the catalog.
- Input based on — not provided (not applicable for service catalog).
7. Extension Points
- Configuration extension (without removing from support): adding custom attributes (e.g., archival volume flag, maximum size of a single file), adding handlers
BeforeWriting/FillingCheckHandlerthrough extension. - Additional checks — control of network path availability and write permissions before saving the volume (through a connected element form handler).
- Additional processing and reports — service processing for migrating files between volumes, inventory of occupied space, searching for "orphans" outside the standard form
RemoveOrphanFilesFromVolume. - Event subscriptions — on writing the catalog item for logging changes to paths/limits.
- Role rights — restricting access to the catalog by the administrator role; fine-tuning through access group profiles.
Requires verification for the specific delivery 3.0.74.2: exact names of module procedures and line numbers, composition of service information registers of the file subsystem, as well as the list of command functions of the list form (integrity check / file transfer) — to be verified in the configurator, as the implementation of the file handling subsystem depends on the version of the built-in BSP.