How to avoid nested transactions when dealing with event subscription?

Question

1C

Good time, colleagues.
Given: SCP configuration (although relevant for any), the document "Receipt of goods and services" (also in its place can be any other), the "On Write" handler in the module of this document and the subscription to the "On Write" event in general of any document in the configuration .
Problem essence:
It is necessary to carry out a certain check at record of any document in system (through a subscription to event). In most cases, processing proceeds normally. But with the exception of the creation / filling of the SF when writing the document "Receipt".
Those. When the "Receipt" document is written, a transaction (Transaction A) is opened, during which the SF document is filled, upon recording of which Transaction B is opened (during the operation of the subscription to the event). An exception occurs in transaction B (the check found the user's cant), respectively, when you try to close transaction A, an exception occurs "There have already been errors in this transaction!".
I don't use "Try... Exception" constructions. Transactions are initiated at the platform level.
For many reasons, the check handler must be on the OnWrite document event.
Can you give any advice on how to avoid nested transactions, or at least correctly handle exceptions in them?
Thank you in advance!

Answer 1

1) Nested transactions do not exist in 1C! Syntactically, you can make a "matryoshka", but it will only be in the code and in the programmer's head. In fact, when a transaction is rolled back from any level of nesting, the top-level transaction is rolled back.
2) The mechanism of subscriptions to events during recording works within the framework of the general transaction of writing objects to the database. Any mistake in subscriptions of this type will result in a total cancellation of the record.
3) Exceptions must be handled with Attempt constructs.
In your case, you need to write your invoice to the database through an attempt; the error message can be retrieved briefly or completely with ErrorInformation() or the simpler ErrorDescription() ; then, depending on the business logic, either inform the user about the error, or write the problem to the log (registration log) for further analysis.