1С Напарник. Стоит он того?

Для таймаутов управляемых блокировок нужно зафиксировать не только ошибку, но и соединение, которое удерживало блокировку. Начните с событий TTIMEOUT, TDEADLOCK и ожиданий TLOCK.

1. Включите сбор на сервере 1С

В logcfg.xml в каталоге conf используемой установки платформы задайте следующую конфигурацию. Ниже — содержимое XML.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="D:\TJ\Locks" history="4">
        <event>
            <eq property="name" value="TLOCK"/>
            <gt property="duration" value="1000000"/>
        </event>
        <event>
            <eq property="name" value="TTIMEOUT"/>
        </event>
        <event>
            <eq property="name" value="TDEADLOCK"/>
        </event>
        <property name="all"/>
    </log>
</config>

Это собирает

• TLOCK — ожидания более 1 секунды; длительность задаётся в микросекундах.

• TTIMEOUT — превышения времени ожидания блокировки.

• TDEADLOCK — взаимоблокировки.

• history="4" — хранение за четыре часа, не ограничение размера журнала.

Путь D:\TJ\Locks — пример для Windows. Выберите каталог с запасом места и предоставьте учётной записи службы сервера 1С права записи. Для Linux нужен соответствующий путь. В многосерверном кластере настройте сбор на узлах, где работают рабочие процессы.

Если журнал уже настроен, добавьте секцию, не уничтожая существующую конфигурацию. Платформа перечитывает настройки автоматически; после изменения проверьте, что файлы журнала действительно появились.

2. Воспроизведите ошибку и найдите участников

Запишите время ошибки, пользователя и выполняемую операцию. В журнале найдите TTIMEOUT и посмотрите

Не путайте номер соединения с номером сеанса. Для поиска блокирующего участника сопоставляйте значения из WaitConnections с t:connectID, учитывая базу и время.

3. Найдите, почему блокирующий участник долго держал транзакцию

Одних событий блокировок может быть недостаточно. На короткое время повторного воспроизведения добавьте сбор

• CALL, SCALL — вызовы;

• SDBL — обращения к данным на уровне платформы;

• DBMSSQL либо DBPOSTGRS — работа с вашей СУБД.

Исследуйте блокирующее соединение, а не только получившее ошибку — что оно выполняло до таймаута и во время ожидания. Ищите длинные запросы, длительную обработку внутри транзакции и обращения к внешним сервисам.

Не включайте все события надолго — контролируйте объём, сохраните нужный интервал и отключите расширенный сбор. Увеличение таймаута само по себе причину не устраняет.

Источник по событиям и фильтрам — «Как отслеживать ожидания на управляемых блокировках» — разделы настройки и поиска причины.

Чтобы настроить технологический журнал для поиска причин таймаутов управляемых блокировок, необходимо:

Включить следующие события в конфигурации технологического журнала:

• EXCP — для регистрации исключений

• TLOCK — для регистрации событий блокировок

• TTIMEOUT — для регистрации таймаутов ожидания блокировок 1

Пример конфигурации (XML):

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="D:\LOGS\Tech_logs" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <event>
            <eq property="Name" value="TLOCK"/>
        </event>
        <event>
            <eq property="Name" value="TTIMEOUT"/>
        </event>
        <property name="all"/>
    </log>
</config>

Дополнительные рекомендации:

• Храните журналы в отдельной директории без посторонних файлов, иначе запись может не выполняться 2

• После настройки подождите 1 минуту и проверьте, что журналы начали создаваться 2

• Для расследования также потребуется файл конфигурации (cf) и реестр кластера 1С ( 1CV8Clst.lst) 1

Идентификация ошибок:

• Ошибки таймаута на управляемых блокировках имеют описание: «Превышено максимальное время ожидания предоставления блокировки» 2

• В событии TLOCK ищите поле WaitConnections, указывающее на соединение, вызвавшее ожидание 3

Источники

1. Рекомендации по сбору данных, необходимых для расследования технологических проблем

2. Мониторинг на продукционных серверах

3. Методика расследования ошибок блокировок

Чтобы подключить новый нетиповой справочник к подсистеме БСП «Версионирование объектов»

1. В определяемый тип ВерсионируемыеДанные добавьте тип
   СправочникСсылка.<ВашСправочник>.

2. В определяемый тип ВерсионируемыеДанныеОбъект добавьте тип
   СправочникОбъект.<ВашСправочник>.
   Подписка ЗаписатьВерсиюОбъекта уже использует этот определяемый тип, событие ПередЗаписью и обработчик общего модуля «ВерсионированиеОбъектовСобытия». Поэтому отдельно добавлять справочник в источник подписки не требуется.

3. В модуле менеджера справочника добавьте экспортную процедуру
   ПриОпределенииНастроекВерсионированияОбъектов. Пустой обработчик допустим. Если нужно скрыть технические реквизиты из отчёта по версиям, включите соответствующую настройку и реализуйте обработчик их получения.

4. В каждой форме элемента справочника вызовите инициализацию подсистемы из события формы ПриСозданииНаСервере

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)

	ВерсионированиеОбъектов.ПриСозданииНаСервере(ЭтотОбъект);

КонецПроцедуры

// Модуль менеджера справочника
Процедура ПриОпределенииНастроекВерсионированияОбъектов(Настройки) Экспорт
КонецПроцедуры

5. Обновите конфигурацию базы данных, включите функциональность «История изменений», затем в настройках истории укажите вариант хранения для нового справочника.

Важно — для справочника используется подписка ЗаписатьВерсиюОбъекта. Подписка ЗаписатьВерсиюДокумента предназначена только для документов. Фрагмент и схема подключения подтверждены документацией БСП 3.2 и кодом подсистемы в выгрузке конфигурации.

Для подключения нового нетипового справочника к подсистеме хранения истории версий необходимо:

1. В конфигураторе установить свойство История данных справочника в значение **Использование ** 1. Это включит версионирование для всего справочника.

2. Создать регламентное задание, которое будет выполнять обновление истории данных по очереди изменений с помощью метода ИсторияДанных.ОбновитьИсторию() 1. Это необходимо для переноса данных из очереди версий в таблицы хранения истории.

3. Настроить выборочное версионирование (при необходимости):

   • Через встроенный язык с использованием метода УстановитьНастройки() и объекта НастройкиИсторииДанных

   • Можно указать конкретные реквизиты для включения/исключения из истории, включая реквизиты табличных частей ( указываются как ТабличнаяЧасть.Реквизит) 1

4. Управление настройками:

   • Включение истории данных через встроенный язык не требует снятия конфигурации с поддержки 1

   • По умолчанию для справочников значение свойства “История данных” - “Не использовать”, поэтому его необходимо включать принудительно 1

Альтернативно можно использовать внешнюю обработку “Настройка и перенос истории данных” для тонкой настройки версионирования объектов метаданных, включая выбор произвольных реквизитов 2.

Источники

1. Глава 26. История данных

2. Настройка и перенос истории данных

Проверку нужно выполнять в модуле объекта документа-партии, в обработчике ОбработкаУдаленияПроведения(Отказ). Если найдены проведённые документы, которые расходовали эту партию, установите Отказ = Истина.

В «Рознице 2.3» отмена проведения также обрабатывается в ОбработкаУдаленияПроведения(Отказ), а наличие связанных записей проверяется запросом через РезультатЗапроса.Пустой().

// Модуль объекта документа, который образует партию.

Процедура ОбработкаУдаленияПроведения(Отказ)

	Запрос = Новый Запрос;
	Запрос.Текст =
		"ВЫБРАТЬ РАЗЛИЧНЫЕ
		|	Расходы.Регистратор КАК ДокументСписания
		|ИЗ
		|	РегистрНакопления.ТоварыПоПартиям КАК Расходы
		|ГДЕ
		|	Расходы.Партия = &Партия
		|	И Расходы.ВидДвижения =
		|		ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход)
		|	И Расходы.Активность
		|	И Расходы.Регистратор <> &Партия";

	Запрос.УстановитьПараметр(
		"Партия",
		Ссылка);

	РезультатЗапроса = Запрос.Выполнить();

	Если РезультатЗапроса.Пустой() Тогда
		Возврат;
	КонецЕсли;

	Отказ = Истина;

	Выборка = РезультатЗапроса.Выбрать();
	ТекстСообщения =
		"Нельзя отменить проведение документа."
		+ Символы.ПС
		+ "Его партия использована в документах:";

	Пока Выборка.Следующий() Цикл
		ТекстСообщения =
			ТекстСообщения
			+ Символы.ПС
			+ Строка(Выборка.ДокументСписания);
	КонецЦикла;

	Сообщить(ТекстСообщения);

КонецПроцедуры

Что заменить на свои имена

• ТоварыПоПартиям — ваш регистр накопления;

• Партия — измерение регистра, в котором хранится ссылка на документ прихода;

• документ партии должен иметь тип, совместимый с этим измерением.

Запрос выполняется по физической таблице регистра, а не по Остатки(). Это важно — остаток покажет только итоговое количество, но не документы-регистраторы, которые уже списывали партию.

Почему проверяется Активность

В физической таблице регистра могут находиться неактивные движения. Условие

Расходы.Активность

оставляет только действующие движения проведённых документов.

Нужно ли дополнительно проверять Регистратор.Проведен

Нет, если движения регистра корректно управляются механизмом проведения — у отменённого документа записи становятся неактивными или удаляются. Для надёжности проверка ведётся по Активность.

Если регистр имеет несколько ресурсов

Сам факт расходного движения не всегда означает, что партия действительно списана — в регистре могут быть служебные расходные строки с нулевым количеством. Тогда добавьте условие по реальному ресурсу, например

|	И Расходы.Количество <> 0

Имя ресурса Количество нужно заменить на фактическое.

Если необходимо показать только первые документы

При большом количестве зависимостей пользовательское сообщение может оказаться слишком длинным. В запросе можно указать

ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 10

и вывести пояснение, что показаны только первые десять документов.

Защита от конкурентного проведения

Для строгого складского учёта одной проверки недостаточно — другой сеанс может провести документ списания одновременно с отменой проведения партии. В промышленной реализации перед чтением зависимых движений нужна управляемая блокировка по измерению Партия. Но основной обработчик и логика отказа остаются такими же — проверка в ОбработкаУдаленияПроведения, затем Отказ = Истина.

В представленных документах отсутствует конкретное описание способа запрета отмены проведения документа при условии, что его партии уже списаны другими документами.

Хотя документы подробно описывают:

• Общий механизм проведения и отмены проведения 1

• Роль обработчиков ОбработкаПроведения() и **ОбработкаУдаленияПроведения() ** 1

• Принципы формирования движений в регистрах 1

Однако ни один из документов не содержит информации о реализации бизнес-логики, которая бы проверяла, были ли партии товара уже списаны другими документами, и запрещала отмену проведения в таком случае.

Для реализации такой функциональности требуется дополнительная разработка в обработчике **ОбработкаУдаленияПроведения() **, включающая проверку наличия зависимых документов, что не описано в предоставленных материалах.

Источники

1. Особенности использования поля “Проведен” и процесса проведения

В БСП 3.2 версионирование прикреплённых файлов уже реализовано «из коробки» в подсистеме Работа с файлами — отдельно разрабатывать ничего не нужно, нужно только включить/подключить механизм.

Как это устроено и как включить

1. У справочника хранения файлов есть булевский реквизит «Хранить версии». Пользователь ставит этот флажок в карточке файла (панель навигации карточки → «Версии файла»). Пока флажок не установлен, при повторном сохранении файла хранится только последняя редакция; если включить — при каждом окончании редактирования создаётся новая запись в подчинённом справочнике «Версии файлов», а активная версия хранится в отдельном реквизите карточки файла.

2. Если ваш объект (справочник/документ) уже подключён к общему справочнику «Файлы» через определяемые типы ВладелецПрисоединенныхФайлов/ВладелецПрисоединенныхФайловОбъект (типовой сценарий для большинства объектов) — версионирование доступно сразу, никаких доработок не требуется — достаточно, чтобы пользователь включил флажок «Хранить версии», либо можно программно проставлять его по умолчанию при создании файла ( ФайлОбъект.ХранитьВерсии = Истина).

3. Если для объекта используется отдельный справочник хранения файлов (вариант с RLS) — по документации нужно повторить у своего справочника ту же структуру, что у типового «Файлы» — булевский реквизит ХранитьВерсии и ссылочный реквизит на подчинённый ему собственный справочник версий (по образцу связки «Файлы» → «Версии файлов»).

Пример реального кода — команда карточки файла «Версии файла» (по коду командного модуля справочника «Файлы»), которая открывает список версий

&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
	
	ПараметрыФормы = Новый Структура;
	ПараметрыФормы.Вставить("Файл", ПараметрКоманды);
	ПараметрыФормы.Вставить("УникальныйИдентификаторКарточкиФайла",
		ПараметрыВыполненияКоманды.Источник.УникальныйИдентификатор);
	
	ОткрытьФорму("Справочник.ВерсииФайлов.Форма.ВерсииФайла", ПараметрыФормы,
		ПараметрыВыполненияКоманды.Источник, ПараметрыВыполненияКоманды.Уникальность, ПараметрыВыполненияКоманды.Окно);
	
КонецПроцедуры

На сервере решение «создать новую версию или перезаписать файл» принимается в общем модуле работы с файлами именно по этому флажку — если у объекта ХранитьВерсии не установлен — данные файла просто обновляются на месте, если установлен — формируется новая запись версии, а прежняя остаётся в истории.

Если у вас свой объект метаданных, для которого файлы ещё не подключены вообще, скажите — подскажу конкретные шаги подключения (определяемые типы, реквизиты, подписки на события) под ваш объект.

Для включения версионирования присоединённых файлов в типовой конфигурации 1С необходимо:

1. Добавить реквизиты в справочник присоединённых файлов — в справочнике ПрисоединенныеФайлы добавить реквизит * ХранитьВерсии* по образцу из демонстрационной конфигурации 1.

2. Настроить типы владельцев файлов — в определяемый тип ВладелецПрисоединенныхФайлов и * ВладелецПрисоединенныхФайловОбъект* включить объекты, для которых требуется вести версионирование 1.

3. Управление настройками через модуль РаботаСФайламиПереопределяемый — использовать процедуру * ПриОпределенииНастроек*, чтобы настроить поведение версионирования (например, разрешить синхронизацию или запретить очистку файлов) для конкретных объектов 1.

4. (Рекомендуется) Использовать обработку ПереходНаВерсию241 для автоматического выполнения необходимых изменений при обновлении 1.

Источники

1. Новое в редакции 2.4

В УТ 11.5 складской остаток и себестоимость ведутся разными контурами. Товар может появиться в регистре «Товары на складах» после складского документа, но не попасть в «Себестоимость товаров», пока не отражён в финансовом учёте.

Основные причины

1. Оформлена складская приёмка, но не проведено приобретение — проверьте связанные документы «Приобретение товаров и услуг» и «Поступление товаров на склад».

2. Не выполнено «Распределение затрат и расчет себестоимости» в закрытии месяца либо этап завершился с ошибкой. По коду УТ именно расчёт себестоимости заполняет партии и формирует движения регистра.

3. Товар принадлежит не вашей организации — комиссионный, ответственного хранения, неотфактурованная поставка. Его стоимость учитывается в другом разделе или по отдельной партии.

4. Не совпадают аналитики — организация, характеристика, назначение, вид запасов либо раздел учёта. Складской регистр ведётся по складу, а себестоимость — прежде всего по организации и ключам аналитики.

5. Остаток создан инвентаризацией или оприходованием излишков, но финансовый документ ещё не оформлен.

6. В списке регистра включён отбор только по конкретному разделу учёта или организации.

По выгрузке УТ 11.5 движения в «Себестоимость товаров» формируются отдельными этапами расчёта

// Подготовка и проверка исходных данных.
РасчетСебестоимостиПодготовкаДанных.ПодготовкаИсходныхДанныхКРасчету(ПараметрыРасчета);
РасчетСебестоимостиПрикладныеАлгоритмы.ПроверитьКорректностьИсходныхДанныхДоРасчета(ПараметрыРасчета);

// Этап формирует движения по регистру "Себестоимость товаров".
РасчетСебестоимостиЗаполнениеПартий.
	ЗаполнениеПартийВРегистреСебестоимостьТоваров(ПараметрыРасчета);

// Для среднескользящей отдельно отражается фактуровка поставок.
РасчетСебестоимостиЗаполнениеПартий.
	ФактуровкаПоставокПриСреднескользящей(ПараметрыРасчета);

Проверять нужно от документа, сформировавшего складской приход — откройте его движения и найдите финансовый документ по той же организации и номенклатуре. Затем запустите закрытие месяца за период поступления и изучите протокол этапа * *«Распределение затрат и расчет себестоимости»**.

Товар может числиться на остатках, но отсутствовать в регистре накопления Себестоимость товаров, если он учитывается в разделах, где не ведется расчет среднескользящей стоимости:

• По запасам в разделе Незавершенное производство среднескользящая стоимость не рассчитывается — учет ведется в разрезе партий производства 1

• По запасам в разделе Неотфактурованные поставки учет стоимости ведется по партиям документов поступления, а не по среднескользящей 1

В таких случаях данные в регистр Себестоимость товаров записываются только при выполнении регламентных операций процедуры Закрытие месяца, а до этого момента товар может быть на остатках, но отсутствовать в регистре себестоимости.

Источники

1. 1С — Управление торговлей 11. Новое в версии 11.5.22.48