Report "UsedExternalResources" — Technical Description

1. Identification

Purpose. Service (administrative) report for auditing the security configuration. It generates a complete list of external resources requested by configuration modules and connected additional modules (extensions, external processing/reports, additional components):

• internet resources (addresses, protocols, ports of outgoing connections);
• file system (directories for read/write);
• COM objects (by ProgID/CLSID identifiers);
• external components (Native/COM);
• launching external applications (OS programs);
• privileged mode / internet access, required by modules.

The result is grouped hierarchically by types of permissions and by software modules that request these permissions. The report is used by the administrator to control permission requests, plan and verify the security profiles of the 1C server, as well as to identify modules that access external resources. Ordinary users do not need it in their daily work.

Where to find in 1C:

• Interface: "Administration" → "External resources used by the program and additional modules".
• Navigation link: e1cib/list/Report.UsedExternalResources

2. Attributes of Header and Table Parts

2.1 Header Attributes

In the report metadata, user-defined header attributes are not defined. The report operates exclusively through the data composition mechanism and programmatic result formation in the object module, without storing parameters in attributes.

2.2 Table Parts

Table parts in the report metadata are absent. All data is generated programmatically through calls to the security subsystem's service API and displayed directly in the resulting tabular document.

2.3 Logical "Fields" of the Result

Although there are no attributes and table parts, the report result programmatically outputs the following semantic columns (formed by the composition scheme/layout):

3. Forms

In the object metadata, the list of forms is empty — no custom forms have been created.

No separate settings form is provided: the set of variants and design is defined programmatically.

4. Key Module Procedures

The attached evidence does not provide BSL module text, typical handlers for reports of this type (service report BSS on DCS) are provided. Exact signatures and presence of procedures require verification in the specific build 3.0.74.2 (BSS version).

4.1 Manager Module

• ConfigureReportVariants(Settings, VariantSettings) — registers the report in the "Report Variants" subsystem: sets visibility (usually service/technical), availability from the report panel, description, and placement. This is where the behavior of the standard form is defined, as there are no custom forms for the report.

4.2 Object Module

• OnResultComposition(DocumentResult, DecodingData, StandardProcessing) — the main handler. Sets StandardProcessing = False and programmatically generates the result: requests from the security subsystem the list of used external resources, collects them into a table/tree of values, composes and outputs to DocumentResult with hierarchical grouping by types of permissions and modules.
• Within the handler, service APIs of BSS are used, for example from modules WorkingInSafeMode, PermissionRequests/SecurityProfiles — to obtain a list of requested permissions for the configuration and additional modules.
• Auxiliary procedures for forming groupings and filling the layout (FormLayout..., AddPermissions...) are possible — the composition depends on the version of BSS.

4.3 What is Important for the Developer

The report does not read business data from registers/reference books. Its source is the metadata of permissions for external resources, registered by modules through the BSS permission request mechanism. Therefore, the result changes when extensions and additional processing are connected/disconnected, rather than when accounting data is changed.

5. Posting and Movements

The object is a report, not a document. Reports in 1C:

• are not posted (there is no PostingProcessing handler);
• do not generate movements in accumulation, information, or accounting registers;
• do not create accounting entries.

Accordingly, for this object, the accounts of the standard chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010), VAT calculations (rate 16% in 2026), PIT/OWP/OSMS/SC, and electronic documents (ESF, CNT) are not applicable. The report only reads service data about permissions and outputs them in a tabular document; it does not perform any records in the information base.

6. Related Objects and Input Based On

• Input based on for reports is not supported by the platform — absent.
• Related objects (subsystem "Security Profiles" / "Working in Safe Mode" BSS):
  • Register(s) of information storage of requested permissions for external resources;
  • Reference of additional reports and processing (source of part of external resources);
  • Configuration extension mechanism (request their own permissions);
  • Common modules WorkingInSafeMode, SecurityProfiles, PermissionRequests (data providers for the report);
  • Processing of security profile settings for the cluster/server where these permissions are actually applied.

7. Extension Points

• Report Variants — adding custom variants/groupings through the "Report Variants" subsystem and ConfigureReportVariants.
• Configuration Extension — overriding/adding the procedure OnResultComposition (for example, adding your justification column or filter by resource type) through annotations &Instead/&After/&Before.
• Registering Custom Permissions — when developing your extensions/additional processing, declare the required external resources through the BSS permission request API; they will automatically be included in the result of this report.
• Access Rights — the availability of the report is regulated by administration roles; when customizing roles, ensure that the report remains accessible only to administrators.

Version-specific (requires verification in 3.0.74.2): the exact composition of auxiliary procedures of the object module and the names of security APIs depend on the version of the built-in BSS.