В процессе разработки конфигураций на платформе 1С:Предприятие 8 каждый программист сталкивается с дилеммой: использовать классическую «старую» методику проведения или перейти на «новую». Выбор методики напрямую влияет на скорость работы системы и поиск узких мест в производительности, вероятность возникновения взаимоблокировок (Deadlocks) и точность расчета себестоимости. В рамках данной статьи мы подробно разберем оба подхода, проанализируем их сильные и слабые стороны, а также выясним, как правильно реализовать контроль остатков и расчет сумм списания при переходе на более современные алгоритмы.
Старая методика проведения — это классический алгоритм, который использовался в системе долгие годы. Ее основной принцип заключается в том, что система проверяет наличие товара на складе до того, как будут сформированы движения по регистру. Чтобы код соответствовал лучшим практикам, рекомендуется использовать шаблоны для применения стандартов и методик разработки конфигураций 1С.
Алгоритм работы старой методики:
Рассмотрим ситуацию на примере. Нам нужно списать 5 единиц товара. Мы сначала спрашиваем у базы: «Сколько у нас есть?». Получаем ответ: «10». После этого мы понимаем, что 5 единиц списать можно, вычисляем их стоимость и записываем расход в базу.
Главный риск: В условиях многопользовательской работы, когда два человека одновременно пытаются списать один и тот же товар, возникают очереди. Первый пользователь заблокировал данные на чтение, второй сделал то же самое. Когда оба пытаются перейти к записи, возникает Deadlock, так как каждый ждет, пока другой снимет свою блокировку на чтение. Если вы столкнулись с подобным, полезно будет проанализировать SQL сервер глазами 1С-ника, чтобы выявить проблемные запросы и ожидания.
Новая методика была предложена фирмой «1С» для оптимизации работы высоконагруженных систем. Основная идея — сократить время нахождения транзакции в состоянии ожидания и исключить конфликты блокировок при чтении.
Алгоритм работы новой методики:
Проанализируем ситуацию: мы не тратим время на предварительное чтение. Мы сразу «застолбили» за собой товар, записав расход. Если после нашей записи остаток стал равен -2, значит, товара изначально не хватало, и мы откатываем операцию. Однако в некоторых бизнес-процессах допускается проведение документов без контроля остатков, что требует гибкой настройки прав доступа.
Разберем подробнее, как выглядит механизм контроля в новой методике. Для этого часто используется свойство набора записей Записывать = Истина. Посмотрим на пример логики в модуле проведения:
// 1. Очистка старых движений (если нужно) и подготовка набора
Движения.ОстаткиНоменклатуры.Записывать = Истина;
Движения.ОстаткиНоменклатуры.Очистить();
// 2. Формирование новых движений на основании данных ТЧ документа
Для Каждого СтрокаТЧ Из ТоварныйСостав Цикл
Движение = Движения.ОстаткиНоменклатуры.ДобавитьРасход();
Движение.Период = Дата;
Движение.Номенклатура = СтрокаТЧ.Номенклатура;
Движение.Количество = СтрокаТЧ.Количество;
КонецЦикла;
// 3. Запись движений в базу данных до выполнения запроса
Движения.Записать();
// 4. Запрос на проверку отрицательных остатков
МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВременныхТаблиц;
// ... (здесь описывается запрос к виртуальной таблице Остатки)
Важным нюансом является использование свойства БлокироватьДляИзменения у набора записей. Это позволяет гарантировать, что данные не будут изменены другими процессами в момент финальной проверки.
Многие разработчики считают, что расчет себестоимости — это исключительная прерогатива старой методики. Действительно, если нам нужно знать остаток суммы до списания, старая методика кажется логичнее. Однако новую методику можно адаптировать, применяя математическую корректировку в запросе. Для оперативного анализа результатов отлично подойдет анализ списания запасов с расчетом себестоимости и цены продажи без закрытия месяца (поможет обработка оперативного расчета себестоимости при проведении документов).
Выясним причину: так как наши движения уже записаны в регистр, запрос к остаткам вернет нам остаток уже после списания. Чтобы получить корректную среднюю цену, нам нужно «виртуально» вернуть списанное количество назад в формуле.
Формула расчета выглядит так:
Цена = СуммаОстатка / (КоличествоОстатка + КоличествоСписанноеДаннымДокументом)
После того как цена вычислена, мы умножаем ее на количество, заполняем поле Сумма в движениях и записываем набор записей повторно. Хотя это кажется «лишним действием», с точки зрения СУБД это эффективнее, чем длительные ожидания блокировок при массовом проведении документов.
Рассмотрим критерии выбора методики для вашего проекта:
Выбирайте Старую методику, если:
Выбирайте Новую методику, если:
Разберем еще один важный аспект. При использовании новой методики 1С предоставляет механизм автоматической оптимизации. Если документ перепроводится, но его данные (номенклатура, количество, дата) не изменились, платформа может сравнить новый набор записей со старым. Если они идентичны, физической записи в таблицы SQL не произойдет.
Этот технический разбор работы с наборами записей подробно объясняет, как использование свойства «Записывать» и анализ модифицированности позволяют ускорить перепроведение документов без лишней нагрузки на СУБД. Это критически важно для производительности: представьте, что бухгалтер просто изменил комментарий в документе — системе нет нужды пересчитывать итоги в регистрах.
Проанализировав ситуацию, можно сделать вывод: новая методика проведения является предпочтительной для большинства современных задач. Она требует чуть более сложного написания запросов, но взамен дает стабильность и масштабируемость системы.
В современных конфигурациях, таких как архитектура проведения в 1С:ERP 2.5, 1С идет еще дальше, разделяя оперативное проведение (только количество по новой методике) и финансовый расчет (себестоимость в конце месяца), что является эталоном разделения ответственности в архитектуре крупных систем. Старая методика остается актуальной только для специфических задач, которые трудно уложить в архитектуру «сначала пиши — потом проверяй».