Desktop version
1C:Enterprise database objects contain the DeletionMark field. This field is used when objects are deleted with reference integrity control. This feature helps to avoid the deletion of an object by a user if the object is referenced from other data stored in the database.
From the platform point of view, direct deletion, i.e. deletion without a reference integrity control, is possible, and the presence of references to missing objects in a database is not an error. The scope of use of this feature is defined by the developer of the configuration and the administrator. The developer of the configuration can control whether direct deletion of certain types of objects can be called by users with the help of Interactive delete rule. For instance, you can disable direct deletion for all users or enable it for some users. This right influences only interactive actions called with standard system commands. If an object is deleted using 1C:Enterprise script tools, you can have this right checked within the module. Of course, direct deletion is also possible in some scenarios, if this is in line with the logics of the task to be solved. This is the case when data is deleted in bulk with a scheduled data processor. In this case, user rights verification is not performed.
Deletion with reference integrity control is a separate service that, however, does not impact other system features. A deletion mark only shows that the user is going to delete the object. The DeletionMark field in 1C:Enterprise does not differ from other system fields of an object in its behavior. It can be set by assigning an object property value, and the object will be marked for deletion after it is written into the system.
You can also use a SetDeletionMark() method instead of setting a deletion mark by directly assigning a value to the object's property and writing this object. This method sets the property to the value specified in the parameter, writes the object and performs other additional actions depending on the type of object. For instance, a posted document is unposted, while all subordinate items of a catalog and subordinate catalogs in a given catalog are marked for deletion. When a user sets the deletion mark using a UI command, actions included in this method are performed. It should be noted, however, that these actions are only a recommended standard way for setting deletion marks. They are not mandatory. If a deletion mark is set by assigning a property value and writing an object, no additional actions are performed. Therefore, the developer can implement setting a deletion mark without any additional actions if needed.
A deletion mark is a field whose value is used during the deletion with reference integrity control, but setting and removing a deletion mark is not a separate, dedicated process from the object point of view. This is why there is no special handler that would accompany the setting and removal of that mark. Just as for any other field of an object, the DeletionMark field value can be analyzed in the BeforeWrite() and OnWrite() handlers to perform certain checks or other actions. If you only need to analyze the value written, it is enough to check the value of the field. If you need to determine whether the changed value was written, you need to read the value of this field from a database and compare the value obtained with the current one in the BeforeWrite() handler.
Note that tabular field extensions contain the BeforeSetDeletionMark events. However, these events accompany only the deletion mark calling with the help of a standard command. This is why these events can only be used to handle the interactive call of a deletion mark in specific forms. If you need to handle common tasks that include control of this field value or perform any deletion mark-related actions, use the events of the object itself.
If the document is marked for deletion, this document cannot be posted. However, a document marked for deletion can have register records, since the posting concept in 1C:Enterprise is not strictly connected with those records. For instance, this is used for documents intended for manual editing of register records. If such documents are marked for deletion, no register records should be deleted in them, as the user can remove a deletion mark and the records will not be lost. You can use 1C:Enterprise script tools in the configuration to disable the activity of register records when a deletion mark is set for such a document. This would be a methodology approach that combines a deletion mark and disabling of register records activity.
Next page: Using the Posted field and the posting process