Report "Control of Report Dispatches" - Technical Description (Accounting for Kazakhstan 3.0.74.2)

1. Identification

Purpose. The report is intended for monitoring and analyzing the history of report distributions in the system. It is used by administrators and specialists responsible for reporting to control the successful delivery of reports to recipients, identify distribution failures, and analyze sending statistics. The report does not perform any data changes — it is exclusively a reading (analytical) object. The frequency of use is daily or weekly, depending on the intensity of distributions in the database.

Important: this is an object of type "Report", not a document. It is not processed, does not generate entries and movements in registers. Section 5 below describes where the report reads data, not what it writes.

Where to find in 1C:

• Navigation link: e1cib/list/Report.ControlReportDistribution
• From the interface: section "Standard subsystems" → "Report distribution control".
• From the directory ReportDistributions — through the context menu of the item (opens the report with the pre-filled parameter ReportDistribution).

2. Attributes of header and table parts

2.1 Attributes

The report does not contain its own attributes in the metadata. All selection and filtering parameters are managed through the DCS mechanism, not through the object's attributes.

2.2 Report parameters (through DCS)

2.3 Table parts

The report does not contain table parts as a metadata object. The resulting table is dynamically formed by the data composition processor based on the data set, the source of which is the information register ReportDistributionHistory. The composition of columns (recipient, address, sending date, status, error text, etc.) is determined by the fields of this register and DCS settings.

3. Forms

Explicit forms in the metadata of the report are not defined (the JSON map does not contain forms).

Since no custom form is specified, the platform generates a standard DCS report form with a settings panel (quick filters, groupings, fields). All user scenarios (changing the period, filtering by status) are implemented using standard DCS tools without form programming code.

4. Key module procedures

In the attached evidence BSL code (object module, manager module, form module) is not presented — custom forms and handlers are absent. The behavior of the object is fully determined by the data composition scheme. Below are typical points that are involved for a report of this type:

• Report object module — usually empty or contains overrides of DCS procedures. Possible typical handlers:
  • OnResultComposition(DocumentResult, DataDecoding, StandardProcessing) — override of result output if additional post-processing of the layout is required.
  • BeforeResultComposition — programmatic adjustment of parameters/selections before selection.
• Data composition scheme (MainDataCompositionScheme) — contains:
  • data set "Request" to the information register ReportDistributionHistory;
  • parameters ReportDistribution, Period, DeliveryStatus;
  • default settings (grouping by distribution/recipient/status, conditional formatting of rows with errors).
• Form module — absent; autoform is used, so there are no user handlers.

Requires verification (version-specific): the exact text of the DCS request and the list of output fields may differ between builds of version 3.0.74; verify against the specific version 3.0.74.2 in the configurator.

5. Data source and construction logic (analogue of posting)

The report does not generate movements and entries — as an object of type "Report", it only reads data. The source is the information register:

• ReportDistributionHistory — stores records of the facts of sending reports to recipients: distribution, recipient, delivery channel (e-mail/other), date-time of sending, delivery status, diagnostic error message.

Construction logic:

1. The DCS processor applies the parameters Period, ReportDistribution, DeliveryStatus.
2. A request is made to the register ReportDistributionHistory with applied filters.
3. The result is grouped (by default — by distribution and status) and displayed in the report form.

Since the object does not affect accounting, accounts from the typical chart of accounts of the RK (for example, 1210, 1030, 3130, 6010) are not involved in its operation — this is a technical/administrative report of the distribution subsystem, not an accounting document. It would be incorrect to present accounting entries here.

6. Related objects and input based on

Input based on is not applied for reports (the "Input based on" mechanism relates to documents/directories). The report opens as a standalone command or from the distribution card.

7. Extension points

• DCS settings (user-defined): adding filters, groupings, conditional formatting (highlighting rows with status "Error"), saving report variants — without modifying the configuration.
• Configuration extension:
  • adding a custom report form for a non-standard interface (filter panels, resend buttons);
  • overriding/extending the composition scheme (new data sets, calculated fields, e.g., "Number of attempts");
  • subscribing to OnResultComposition in the object module through an extension for post-processing the layout.
• Integration: adding new dimensions/resources to the register ReportDistributionHistory (channel, external service identifier) with subsequent output in the report.
• Scheduled tasks: refining the procedure for populating the distribution history (detecting subscription limits, delivery statuses) is automatically reflected in the report, as it reads the same register.

Requires verification (version-specific): the names of resources/dimensions of the register ReportDistributionHistory and the set of delivery statuses may differ between releases; document the actual structure in the configurator of version 3.0.74.2.