1. Identification
| Parameter | Value |
|---|---|
| Object Type | Report |
| Name | LinkUsagePlaces |
| Full Name | Report.LinkUsagePlaces |
| Synonym | “Link usage places” (no separate custom synonym in metadata is specified, the object name is used) |
| Configuration | Accounting for Kazakhstan, ed. 3.0.74.2 |
| Mechanism Basis | Library of standard subsystems (BSP), subsystem “Search and delete marked objects / Service events” |
| Navigation Link | e1cib/list/Report.LinkUsagePlaces |
Purpose. The report is intended for analyzing the relationships between objects in the information base and finding all places where a specific link (or set of links) to an object is used — a directory element, document, chart of accounts, characteristic, etc. It is used by administrators, accountants, and developers/implementers for:
- analyzing dependencies before deleting or replacing an object (counterparty, nomenclature, cost item, account, etc.);
- controlling the referential integrity of the database;
- auditing relationships between objects.
The report is generated on demand: the launch command is available in the context menus of lists and object forms (if the appropriate rights are available), as well as directly via the navigation link. The result is built dynamically, the object does not store or modify any data.
Where to find in 1C: context menu of the element (directory/document) → “Usage places” / “Show related objects”; or direct transition via the link e1cib/list/Report.LinkUsagePlaces.
2. Header Attributes and Table Parts
2.1 Header Attributes
The report does not contain its own header attributes in metadata.attributes. All parameterization is performed through the data composition system (DCS) and is passed programmatically upon opening.
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| (attributes absent) | — | — | The report operates through DCS parameters passed programmatically |
In fact, the controlling input parameter is the set of analyzed links — it is passed to the report from outside (from the context menu command) and enters the data composition parameters, not the object attributes.
2.2 Table Parts
Table parts are absent. The report is not a document and does not store structured data in the object model — the result (list of usage places) is generated dynamically by the data composition scheme at the time of output.
2.3 Forms
In metadata.forms the list is empty. The report uses a universal (auto-generated) report form of the 1C:Enterprise platform. The interface is built automatically based on the data composition scheme.
| Form | Type | Purpose |
|---|---|---|
| Standard report form | Auto-generated (DCS) | The only working form: displays the tree/list of objects referencing the analyzed object; manages settings, filters, and grouping |
3. Forms — List and Purpose
The object has no own forms. The user always works with the standard report form, which the platform generates from the main data composition scheme. In this form, the following are available:
- result area (table document) with a list of usage places;
- DCS settings panel (filters, groupings, formatting) — if it is opened by the user;
- commands for generating, updating, and saving/printing the result.
4. Key Module Procedures
The own BSL code (object module, form module) in evidence for this report is not attached — the report is implemented declaratively through DCS and is serviced by BSP mechanisms. Below are the typical handlers of this type of object (BSP service report “Link usage places”):
| Location | Handler / Method | What it does |
|---|---|---|
| Report object module | OnResultComposition(DocumentResult, DataDecoding, StandardProcessing) |
Intercepts standard composition: programmatically fills the data source with the list of usage places of the passed links and outputs the result in a table document |
| General BSP mechanism | FindByLinks(ArrayOfLinks) (platform method) |
Returns a table of IB objects in the attributes/movements of which each of the analyzed links is found — the report database |
| Form module (auto) | OnCreateOnServer / OnOpen |
Receiving the parameter with the link(s), initializing DCS settings, automatic generation upon opening |
| Form module (auto) | Generate / UpdateResult |
Re-running composition based on user action |
| Form module (auto) | Decoding handler | Opening the object usage place by double-clicking the result row |
Requires verification on a specific release: the exact composition of export procedures of the object module — it depends on the version of BSP embedded in 3.0.74.2.
5. Posting and Movements
The object is a report, not a document: it is not posted, does not generate postings and movements in any register. This is fundamental — the report works only in read mode and does not change the state of the information base.
The report only displays existing relationships. For example, when analyzing a counterparty, the result may show that documents and registers that participate in the standard accounting logic of the RK configuration reference it:
- sales documents that generate postings according to the typical chart of accounts of the RK:
Dr 1210 Cr 6010— reflecting revenue from sales (short-term receivables from customers / revenue from sales);Dr 1210 Cr 3130— VAT on sales (to be paid) at a rate of 16%;Dr 7010 Cr 1330— write-off of the cost of sold goods;
- incoming and payment documents:
Dr 1330 Cr 3310,Dr 3310 Cr 1030; - registers of accounting calculations, ESF (ESF IS), SCT, etc.
All the listed postings are generated by the documents themselves, not by the report. The report only shows where the analyzed link is involved.
6. Related Objects and Input on Basis
- Input on basis is not applicable — this mechanism is not applicable to the report by definition.
- Source of call: commands from the context menus of lists and forms of directories/documents (“Usage places”, “Related objects”), general BSP commands.
- Adjacent service objects of BSP: processing for searching and deleting marked objects, link replacement mechanism, report on broken links. “Link usage places” is a mandatory step before deletion: it shows which objects will become “broken” when the analyzed link is deleted.
- Analyzed objects: any IB object to which links are allowed — directories (Counterparties, Nomenclature, Organizations, Individuals), documents, charts of accounts (1210, 1030, 1330, 3310, 3130, 6010, 7010, etc.), plans of characteristic types, registers.
7. Extension Points
- Configuration extension. The report can be borrowed into an extension and the data composition scheme or the
OnResultCompositionhandler can be overridden to add custom groupings/filters of the result. - DCS settings. Through user settings of the form (filters, groupings, conditional formatting) — without changing the configuration.
- Programmatic call. The report can be opened programmatically by passing an array of links in the parameters, for embedding “dependency analysis” in custom processing before deleting objects.
- BSP mechanisms. The search logic relies on the platform
FindByLinksand general modules of the object search/deletion subsystem — their behavior is configured using standard BSP tools, not by modifying the report itself.
Requires verification on a specific release: the names of general modules and the composition of BSP commands involved in calling the report — they are version-dependent and may differ within the 3.0.74.x line.