Это все диагностика
Технологический журнал платформы 1С - это важнейший инструмент в части диагностики и расследования проблем стабильности и производительности, а также, фактически, единственный официальный способ понять что происходит в работе платформы. Имея достаточно гибкие настройки, его можно использовать как для постоянного сбора данных в целях мониторинга работы системы, так и для расследования конкретных вопросов.
Сегодня мы пробежимся по почти всем событиям технологического журнала и рассмотрим примеры работы с ними и действия, которые их создают. Некоторые из событий мы рассмотрим подробней, а некоторые очень кратко, т.к. у них особая специфика, которую даже не всегда можно воспроизвести.
Весь материал ниже должен помочь в быстром старте при работе с технологическим журналом и пониманием что к чему, но вопрос самой настройки и анализа останется за бортом. Для изучения этих вопросов рекомендую обратиться к следующим материалам:
- Настройка параметров технологического журнала на ИТС
- Примеры настроек технологического журнала на ИТС
- Небольшая серия статей про технологический журнал для новичков (описание, настройка, анализ)
В конце публикации также даны ссылки на другие, более сложные материалы. Особенно хотел бы выделить серию публикаций Николая Васильева, в которых рассказано о работе с технологическим журналом с помощью регулярных выражений. Материалы выглядят недооцененными, рекомендую ознакомиться всем, кого эта тема интересует. Надеюсь, когда-нибудь материалы по этой теме будут выпускаться вновь.
И так, поехали! Нас ждет экскурсия по событиям технологического журнала.
В самых общих чертах
Для начала использования технологического журнала необходимо сформировать файл настроек logcfg и поместить его в каталог:
C:\Program Files\1cv8\conf\logcfg.xml
а если у вас 32-битное приложение, то сюда:
C:\Program Files (x86)\1cv8\conf\logcfg.xml
Конечно, у Вас могут быть вообще не стандартные пути установки платформы 1С, поэтому смотрите по ситуации. Файл настроек должен содержать как фильтр отбираемых событий, так и отборы по их свойствам, настройки сбора дампов и другое. Вот так выглядит простая настройка сбора информации об ошибках.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="D:\1CLogs\Errors\" history="120">
<event>
<eq property="name" value="admin"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="qerr"/>
</event>
<event>
<eq property="name" value="scom"/>
</event>
<property name="all"/>
</log>
</config>
После этого указанные события с учетом фильтров будут записываться в текстовом формате в файлы логов в разрезе каталогов процессов.
Кроме указанных событий и фильтров к ним, в ТЖ можно настроить формирование дампов, планов запросов, сбор системной информации и кое-что еще. Мы сосредоточимся именно на описании событий и примеров их использования. Подробнее о файле настроек Вы можете узнать по предложенным ссылкам выше.
Анализировать данные файлов журнала можно с помощью текстового редактора, если они не большие, инструментов разработчика от Сергея Старых, регулярных выражений, перезаливкой логов в другие хранилища (базы данных или ElasticSearch) и другими удобными способами.
Вы можете поделиться в комментариях тем как Вы обрабатываете эти массивы данных.
События и примеры
В платформе 8.3.17 насчитывается больше 40 событий, доступных для сбора. Для удобства разбил их все на категории, но с некоторыми допущениям. То есть эта классификация больше для удобства при ознакомлении. В работе события из разных категорий очень часто соседствуют друг с другом в одном файле настроек и дополняют друг друга при анализе.
Начнем с наиболее популярных событий.
Самые используемые события
События, которые приходиться использовать чаще всего.
Самый распространенный способ использования ТЖ - это получение информации об ошибках. Это могут быть как ошибки конфигурации, так и ошибки самой платформы 1С из-за багов или особенностей окружения. В общем случае для этих целей используются:
- EXCP - Исключительная ситуация приложения системы «1С:Предприятие», которое штатно не обрабатывается и может послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса
- EXCPCNTX - Событие, которые началось, но не закончились в момент возникновения нештатной ситуации
Обычно в файл настройки ТЖ добавляют именно событие EXCP, т.к. событие EXCPCNTX идет обычно следом, даже если явно не было добавлено в отбор. Событие EXCP, а EXCPCNTX дополняет его информацией о тех событиях, которые выполнялись и не были завершены в момент этого исключения. При этом событий контекста исключения может быть несколько. Подробнее об особенностях вывода контекстов исключений можно ознакомиться на ИТС. Оба события имеют следующие составы.
| Категория события | |||
| Событие | Описание | Служебное имя | |
| Свойство | Описание свойства | Служебное имя свойства | Тип значения свойства |
| Диагностика ошибок | |||
| Исключение | Исключительная ситуация приложения системы «1С:Предприятие», которое штатно не обрабатывается и может послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса | EXCP | |
| TCP соединение | Номер TCP соединения между процессами системы «1С:Предприятие» | t_clientid | Строка |
| Адрес базы данных | Адрес базы данных, в формате "<имя_сервера>\<имя_базы_данных>" | Database | Строка |
| Действия | Наименование выполняемого действия | func | Выполняемое действие |
| Длительность события в сотнях микросекунд | Длительность события в сотнях микросекунд | duration | Число |
| Длительность события, мкс | Длительность события в микросекундах | durationus | Число |
| Имя исключения | Наименование программного исключения | exception | Строка |
| Имя копии базы данных | имя копии базы данных | DBCopy | Строка |
| Имя пользователя ИБ | Имя пользователя информационной базы | usr | Строка |
| Имя процесса | Наименование приложения, как его представляет операционная система (имя файла загрузочного модуля приложения) | Process | Строка |
| Имя серв. контекста | Имя серверного контекста, который обычно совпадает с именем информационной базы | p_processname | Строка |
| Имя события | Имя события | name | Строка |
| Имя файла с дампом | Имя файла с дампом | dumpfile | Строка |
| Исключение ОС | Описание исключения операционной системы | osexception | Строка |
| Компьютер соединения | Имя компьютера процесса, установившего соединение | t_computername | Строка |
| Контекст | Контекст исполнения | context | Строка |
| Номер сеанса | Номер сеанса | sessionid | Число |
| Описание исключения | Пояснения к программному исключению | descr | Строка |
| Ошибка дампа | Описание ошибки, произошедшей в процессе построения дампа | dumperror | Строка |
| Приложение соединения | Идентификатор приложения, установившего соединение | t_applicationname | Строка |
| Соединение с ИБ | Номер соединения с информационной базой | t_connectid | Строка |
| СУБД | СУБД источника данных | dbms | Тип СУБД |
ТОП-6 инструментов для разработчика 1С
Подборка лучших инструментов для разработчика 1С включает Toolkit, DCT, OneDebugger, PrintWizard, DataFormWizard и Infostart MCP. Любой инструмент со скидкой 20% при покупке от двух решений.
Вступайте в нашу телеграмм-группу Инфостарт
логи технологический журнал события диагностика платформа 1С мониторинг
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Технологический журнал Программист 1С 8.3 Россия Бесплатно (free)
Устал парсить ТЖ 1С gawk-скриптами каждый раз заново - собрал нормальный инструмент. DuckDB под капотом, разбор ТЖ, планов под MS SQL и PostgreSQL, AI-объяснения опционально.
08.07.2026 4812 nazarovss 33
Технологический журнал Системный администратор Программист Бесплатно (free)
Чтобы перейти от тушения инцидентов в 1С к превентивному подходу, нужно заранее видеть рост данных, блокировок, времени выполнения операций и другие признаки будущих проблем. Разбираем, какие метрики технологического журнала 1С и СУБД стоит мониторить в реальном времени и как использовать простые ML-модели – регрессию и классификацию – для прогноза падения производительности. Объясняем, как автоматически выявлять аномалии в поведении пользователей и фоновых заданий, настраивать proactive-алерты за часы или дни до инцидента и создавать тикеты в ITSM-системах на превентивные действия.
02.07.2026 3819 aidar_safin 17
Технологический журнал Программист Бесплатно (free)
Парсинг техжурнала 1С – это не просто «распарсить JSON» или CSV, а работа с множеством неочевидных особенностей формата. Показываем, какие проблемы могут возникнуть из-за дублей свойств и событий, «полей-призраков», нестандартных имен свойств, разрозненного контекста, кавычек, апострофов и других нюансов, которые легко ломают парсеры и искажают результаты анализа. Объясняем, чем может помочь ИИ при работе с техжурналом и почему даже при использовании современных инструментов важно понимать внутреннюю логику логов. В статье собраны главные правила надежного парсинга и примеры ситуаций, где техжурнал может неожиданно показать свою «темную сторону».
17.06.2026 4359 Andreynikus 9
Технологический журнал Мониторинг Программист 1С 8.3 Абонемент ($m)
Решение-заготовка для автоматического мониторинга и расследования технологических инцидентов в случаях невозможности использования решений КИП.
1 стартмани
29.05.2026 2348 8 tori131313 3
Linux Технологический журнал 1С:Предприятие 8 Бесплатно (free)
Графическая утилита, сделанная по принципу Microsoft SQL Server Profiler, но для СУБД PostgreSQL Позволяет легко настраивать сбор планов запросов как средствами PostgreSQL, так и технологическим журналом 1С Предприятие с их последующей визуализацией. Простая, понятная для пользователей утилита, не требующая прав администратора для визуализации, и требующая их для настройки. Скомпилированная в исполняемый файл.
20.05.2026 3910 capitan 4
HighLoad оптимизация Технологический журнал Системный администратор Программист 1С 8.3 Бесплатно (free)
Пошаговая методика поиска утечек памяти в 1С через технологический журнал: как связать события CALL и LEAKS по clientID, агрегировать тысячи строк стеков вызовов в компактное дерево сценариев, классифицировать проблему без открытия конфигуратора и упаковать результат в готовую задачу разработчику — с bash-скриптами для каждого шага и разбором на реальном примере
17.04.2026 5093 maraty 9
HighLoad оптимизация Технологический журнал Программист Бесплатно (free)
Пользователи жалуются на медленную работу 1С, система нестабильна под нагрузкой, а попытки «починить» не дают результата? В статье разбираем, как подойти к оптимизации производительности комплексно: от анализа инфраструктуры и базы данных до уровня кода и пользовательских операций. Показываем пошаговый подход «аудит – оптимизация – контроль» и объясняем, какие инструменты помогают быстро выявить и устранить узкие места. На реальном примере проходим путь от первичного мониторинга до внедрения оптимизаций и стабилизации системы.
06.04.2026 2934 kulmaksim 0
HighLoad оптимизация Технологический журнал Программист 1С 8.3 1С 8.5 Абонемент ($m)
tjclick - кроссплатформенная утилита для копирования логов технологического журнала платформы 1С в КликХаус
10 стартмани
02.04.2026 1383 1 SerVer1C 0
В качестве добавления приведу фрагмент из своих записей:
Иногда приходится анализировать почему происходит реструктуризация базы, хотя предпосылок к этому вроде бы и нет. ТЖ с приведенными настройками поможет понять что именно и почему реструктуризируется. Найдено на партнерском форуме. Там же мне попадалась фраза сотрудников 1С о том, что в документации описано только около 10% возможностей ТЖ.
<system level="Debug" class="AccntDBStru"/>
<system level="Debug" class="BackEndDBStru"/>
<system level="Debug" class="MDAnalyser"/>
<system level="Debug" class="DBFileStoreStru"/>
<system level="Debug" class="DBStruManager"/>
<system level="Debug" class="ExtensionsDBStru"/>
<system level="Debug" class="FtextDBStru"/>
<system level="Debug" class="IBVersionStru"/>
<system level="Debug" class="SystemSettingsStorageDBStru"/>
<system level="Debug" class="UsersDBStru"/>
<system level="Debug" class="BasicDBStru"/>
<system level="Debug" class="BPDBStru"/>
<system level="Debug" class="CalcDBStru"/>
<system level="Debug" class="HistoryStorageDBStru"/>
<system level="Debug" class="EDBConnectionParametersDBStru"/>
<system level="Debug" class="ODataDBStru"/>
<log location="E:\1c_TechLogs\Restructuring" history="8">
<event>
<eq property="EventType" value="Workflow"/>
</event>
<event>
<eq property="EventType" value="Analysis"/>
</event>
<event>
<eq property="EventType" value="Restructuring"/>
</event>
<property name="all"/>
</log>
Показать<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<system level="trace"/>
<log history="48">
<property name="all"/>
<event>
<eq property="EventType" value="Workflow"/>
</event>
<event>
<eq property="EventType" value="Analysis"/>
</event>
<event>
<eq property="EventType" value="Restructuring"/>
</event>
</log>
<dump create="false"/>
</config> ПоказатьА Вам доводилось использовать для расследования таймаутов блокировок СУБД свойства lka, lkp и иже с ними? В документации очень скудное описание работы этих параметров. Единственное для чего мне удалось их приспособить - это для отборов в настройках ТЖ. Номера "соединений", которые перечисляются в списках источников/жертв похоже ни с чем в ТЖ не коррелируют. По крайней мере, я не понял как это использовать.
Можете подсказать, что за значения в параметрах lkpid, lkaid и как их использовать?
Всё описание этого функционала в документации укладывается в 3 строчки:
В ИТС все расписано: ()
Блокировочные свойства событий:
● lka=‘1’ – поток является источником блокировки.
● lkp=‘1’ – поток является жертвой блокировки.
● lkpid – номер запроса к СУБД, «кто кого заблокировал» (только для потока-жертвы блокировки). Например, ‘423’.
● lkaid – список номеров запросов к СУБД, «кто кого заблокировал» (только для потока-источника блокировки). Например, ‘271,273,274’.
● lksrc – номер соединения источника блокировки, если поток является жертвой, например, ‘23’.
● lkpto – время в секундах, прошедшее с момента обнаружения, что поток является жертвой. Например: ‘15’.
● lkato – время в секундах, прошедшее с момента обнаружения, что поток является источником блокировок. Например, ‘21’.
Пока готовил уточняющий вопрос, похоже сам разобрался. Поправьте, если не прав, пожалуйста.
Есть событие с такими значениями:
lkp=1,lkpid=563,lksrc=77765,
Здесь, lkp=1 означает что данный поток (сеанс, соединение) ожидает установки блокировки.
lkpid - собственно идентификатор этого потока (жертвы)
lksrc - это номер соединения-источника блокировки (того, которого ждем).
Я как раз обычно пользуюсь свойством lksrc для поиска источника. А вот как использовать lkpid и lkaid не мог понять.
Сейчас обратил внимание, что у соединения-источника блокировки, найденного по 'lksrc=77765', в списке lkaid как раз присутствует значение, равное lkpid жертвы. То есть у источника приводится список жертв, которых он блокирует.
t:connectID=77765,...,lka=1,lkaid='35,549,551,552,553,554,556,557,558,559,560,561,562,563,564,.....,1360,1362,1363,1364,1365,1366',lkato=99
Кстати, может быть подскажете что означают буквы a и p (слово от которого сокращение)? Насчет lk полагаю, что это от LOCK
В запросе-источнике будет к примеру "lkaid=1,2,3", а так-же в ТЖ будут 3 запроса-жертвы, у которых в описании будет запись lkpid=1, lkpid=2, lkpid=3 (соответственно)
Статья збс.
Можно через тех. журнал отследить все обращения к одной таблице? Например, РегистрСведений.ГрафикиРаботыПоВидамВремени (_InfoRg16553). Есть подозрение, что часть запросов не оптимальны, но как поймать откуда они идут? Из дополнительной обработки, из документа, отчета?
Дополните, пожалуйста такую информацию по событиям:
После имени любого события идет цифра:
SCALL,4
CALL,2
На сколько я понял, это уровень вложенности (иерархии) события - какое событие внутри какого вызвалось. Событие с самым маленьким числом - это самая большая "матрешка", далее в нее вкладываются другие "матрешки" и пошел счетчик, то есть "матрешка" с самым большим числом - самое нижнее событие.
08:11.966000-15995,SCALL,4,process=1CV8C,OSThread=16492,ClientID=22,Interface=bc15bd01-10bf-413c-a856-ddc907fcd123,IName=IVResourceRemoteConnection,Method=0,CallID=23994,MName=send,DstClientID=9,Context='
ВнешняяОбработка.ТестированиеТехнологическогоЖурнала.Форма.Форма.Форма : 11 : Результат = ВызовСервераНаСервере();'08:11.954004-16003,CALL,2,process=rphost,p:processName=MyTempDbHost,OSThread=20384,t:clientID=9,t:applicationName=1CV8C,t:computerName=YY-COMP,t:connectID=25,callWait=0,first=true,Usr=DefUser,SessionID=5,Context=Форма.Вызов : ВнешняяОбработка.ТестированиеТехнологическогоЖурнала.Форма.Форма.Модуль.ВызовСервераНаСервере,Interface=bc15bd01-10bf-413c-a856-ddc907fcd123,IName=IVResourceRemoteConnection,Method=0,CallID=23994,MName=send,Memory=88594,MemoryPeak=1038217,InBytes=3461,OutBytes=0,CpuTime=0Не могу найти кто регистрирует данные в узел, а в журнал регистрации это событие не пишется(
DBMSSQL,DataBase=192.168.30.161\trade11,Trans=0,Func=insertRecords,tableName=#T13cb57ec58cb4545b4340a98c8af0955,Sdbl='
INSERT #T13cb57ec58cb4545b4340a98c8af0955
VALUES(
После чего 150 тысяч строк, что входит в скобки "VALUES". Ну и лог соответственно за час пухнет до сотен МБ. Что означает данная запись?
INS ERT #T13cb57ec58cb4545b4340a98c8af0955
VALUES(
После чего 150 тысяч строк, что входит в скобки "VALUES". Ну и лог соответственно за час пухнет до сотен МБ. Что означает данная запись?
Он в свойство записал весь запрос, в запросе у вас видимо совсем много записей, если вам свойство Sdbl не нужно можно его не включать, реализуется по типу(или уменьшить время очистки лога ТЖ):
<event>
<eq property="Name" value="CALL"/>
<eq property="p:processName" value="MyProcess"/>
<ge property="Duration" value="1000"/>
<ne property="Context" val ue=""/>
</event>
<property name="Usr"/>
<property name="Context"/>
<property name="Memory"/>
<property name="MemoryPeak"/>
Закрытие месяца.РасчетПартийИСебестоимости
При выполнении операции закрытия месяца "Распределение затрат и расчет себестоимости" произошла ошибка:
Аварийно завершился рабочий процесс фонового задания
8.3.19.1150, КЭШ сбрасывал, интервал перезапуска 86400, то есть сутки, многопоточность урезал.
перенес выгрузкой базу на другой сервер и 8.3.18.1289 - там 8 часов и получил ошибку по остаткам, то есть штатно отработала. смотрю ЖР в основной - в RPHOST пишет, что потеряно соединение с процессом........
Connection removed from ping direction: address=...
..
Outgoing connection closed
- это все перед "аварией" - вроде как закрывает соединение из-за ?? может какой сетевой интерфейс разрывает соединение с фоновым заданием по таймауту? адрес fe80::1c1f:14eb:be36:22d%11 - потом делает попытку зацепится за него же и отваливается снова. (в 21:48 авария)
лог |
|---|
| 1:45.601005-0,CONN,0,process=rphost,OSThread=1412,Txt='Connection removed from ping direction: address=[fe80::1c1f:14eb:be36:22d%11]:1641,pingTimeout=5000,pingPeriod=1000,lastSentTs=2722998935,lastReceivedTs=2722998935,lastReceivedTestTs=(2722995846,2722995846,2722996876,2722996876,2722997905,2722997905,2722998935,2722998935),clientID=465313'
21:45.601006-129707003,CONN,0,process=rphost,OSThread=11936,ClientID=465313,Txt=Outgoing connection closed 21:45.601009-0,CONN,0,process=rphost,OSThread=1412,Txt='Connection removed from ping direction: address=[fe80::1c1f:14eb:be36:22d%11]:1641,pingTimeout=5000,pingPeriod=1000,lastSentTs=2722998935,lastReceivedTs=2722998935,lastReceivedTestTs=(2722995846,2722995846,2722996876,2722996876,2722997905,2722997905,2722998935,2722998935),clientID=465314' 21:45.601010-120581007,CONN,0,process=rphost,OSThread=7212,ClientID=465314,Txt=Outgoing connection closed 21:45.679008-0,CONN,1,process=rphost,OSThread=6836,ClientID=465326,Protected=0,Txt='Connected, client=(23)[fe80::1c1f:14eb:be36:22d%11]:64372, server=(23)[fe80::1c1f:14eb:be36:22d%11]:1641, marker=1' 21:45.679009-0,CONN,1,process=rphost,OSThread=6836,Txt='Connection added to ping direction: address=[fe80::1c1f:14eb:be36:22d%11]:1641,pingTimeout=5000,pingPeriod=1000,lastSentTs=2722998935,lastReceivedTs=2722998935,lastReceivedTestTs=(2722995846,2722995846,2722996876,2722996876,2722997905,2722997905,2722998935,2722998935),clientID=465326' 21:45.679010-0,CONN,1,process=rphost,OSThread=6836,Txt=Clnt: MyUserName1: Администратор@SRV 21:45.679012-0,CONN,1,process=rphost,OSThread=12084,ClientID=465327,Protected=0,Txt='Connected, client=(23)[fe80::1c1f:14eb:be36:22d%11]:64373, server=(23)[fe80::1c1f:14eb:be36:22d%11]:1641, marker=1' 21:45.679013-0,CONN,1,process=rphost,OSThread=12084,Txt='Connection added to ping direction: address=[fe80::1c1f:14eb:be36:22d%11]:1641,pingTimeout=5000,pingPeriod=1000,lastSentTs=2722998935,lastReceivedTs=2722998935,lastReceivedTestTs=(2722995846,2722995846,2722996876,2722996876,2722997905,2722997905,2722998935,2722998935),clientID=465327' 21:45.679014-0,CONN,1,process=rphost,OSThread=12084,Txt=Clnt: MyUserName1: Администратор@SRV 21:45.679017-0,CONN,1,process=rphost,OSThread=6836,Txt=Clnt: DstUserName1: SRV\????????????? StartProtocol: 0 Success 21:45.679019-0,CONN,1,process=rphost,OSThread=12084,Txt=Clnt: DstUserName1: SRV\????????????? StartProtocol: 0 Success 21:45.679023-0,CONN,1,process=rphost,OSThread=6836,Txt=Clnt: MyUserName2: SRV\Администратор 21:45.679026-0,CONN,1,process=rphost,OSThread=12084,Txt=Clnt: MyUserName2: SRV\Администратор 21:47.270001-0,CONN,0,process=rphost,OSThread=3068,Txt='Ping direction statistics: address=[fe80::1c1f:14eb:be36:22d%11]:1641,pingTimeout=5000,pingPeriod=1000,period=10296,packetsSent=10,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=1,packetsLostAndFound=1' 21:57.566000-0,CONN,0,process=rphost,OSThread=3068,Txt='Ping direction statistics: address=[fe80::1c1f:14eb:be36:22d%11]:1641,pingTimeout=5000,pingPeriod=1000,period=10296,packetsSent=10,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=1,packetsLostAndFound=1' Скрытый текст |
вопрос к автору - в какие логи в таком случае надо смотреть в первую голову? к слову после ввода настроек как в статье EXCP и
EXCPCNTX у меня не появились.
На серверах настройки одинаковые, но сами сервера и в т.ч. оси разные
168000-15997,ADDIN,2,process=1cv8c,OSThread=5368,Func=ExternalEvent,Location=C:\Program Files (x86)\1C-Rarus\SoftPhone\NativeComponent\x32\SP_ClientNative.dll,Source=SoftPhone,Message=OnLinesStatus,Result=0
Как правило, контекст не пишется для внешних отчетов / обработок, в том числе, если это подключенный из внешней обработки алгоритм заполнения табличной части.
Когда контекст будет идти отдельным событием Context, которое может быть чуть раньше или чуть позже события SDBL.