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

Для таймаутов управляемых блокировок нужно зафиксировать не только ошибку ^[4], но и соединение, которое удерживало блокировку. Начните с событий 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:TJLocks" 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:TJLocks — пример для Windows. Выберите каталог с запасом места и предоставьте учётной записи службы сервера 1С права записи. Для Linux нужен соответствующий путь. В многосерверном кластере настройте сбор на узлах, где работают рабочие процессы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="D:LOGSTech_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 ^[7]

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

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

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

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

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

Источники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники

1. Новое в редакции 2.4 ^[13]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники

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