Скажу вам, что отличает опытного 1С-разработчика от новичка. Нет, это не количество сертификатов и не толщина резюме.
Опытный специалист знает, как работают типовые механизмы изнутри — и поэтому не изобретает велосипед каждый раз, когда клиент просит что-то доработать. Он берёт готовый механизм, понимает его логику и либо использует как есть, либо аккуратно расширяет.
У меня уже за плечами больше двенадцати лет работы с 1С, и за это время я видел всякое: проекты, где разработчик написал свой собственный механизм проведения документов вместо использования стандартного — и потом полгода чинил баги. Видел конфигурации, где подсистема обмена данными была реализована с нуля, хотя в типовой есть прекрасный готовый фреймворк.
Незнание типовых механизмов стоит денег — и немалых. Поэтому давайте сегодня расслабимся и пошутили над самыми важными из них.
Типовые конфигурации 1С — это не просто набор справочников и документов.
Это целая экосистема готовых решений, которые фирма «1С» разрабатывала и шлифовала годами. Каждый механизм — это накопленный опыт тысяч внедрений, обкатанный на реальных предприятиях с реальными данными.
Когда вы открываете 1С:Бухгалтерию ПРОФ или 1С:Управление торговлей, вы получаете не просто программу для учёта. Вы получаете:
И это только верхушка айсберга. Умение работать с этими механизмами — ключевой навык любого 1С-специалиста, который хочет делать качественные доработки, не ломая при этом типовую функциональность.
Начнём с самого фундаментального.
Проведение документа в 1С — это не просто «нажал кнопку, записались движения». За этим стоит целая цепочка событий, и понимать её критически важно.
Когда пользователь нажимает «Провести», платформа запускает следующую цепочку:
Казалось бы, всё просто.
Но вот типичная ошибка: разработчик пишет тяжёлые запросы в обработчике ПередЗаписью, хотя для этого есть специальное место — ОбработкаПроведения. В результате даже простое сохранение документа без проведения начинает тормозить.
Вот как выглядит правильная структура обработчика проведения в типовых конфигурациях:
Ключевой принцип: один запрос на всю табличную часть, а не запрос в цикле.
Это правило нарушается так часто, что я уже перестал удивляться. Видел документ на 500 строк, где в цикле выполнялось 500 отдельных запросов — проведение занимало 40 секунд. После рефакторинга — 2 секунды.
В типовых конфигурациях существуют два режима проведения, и путаница между ними — источник многих проблем.
Оперативный режим работает только для документов текущей датой и блокирует данные для контроля остатков. Неоперативный режим используется для прошлых периодов и не выполняет контроль остатков в реальном времени.
Типовые конфигурации умеют автоматически определять режим проведения и переключаться между ними.