В каждой живой базе 1С есть задачи, которые повторяются: раз в сезон, раз в месяц, раз в неделю. Их объединяет одно — руками это сотни однотипных правок, по одному полю на карточку. Ровно для таких задач существуют внешние обработки: файл .epf, который подключается к базе без изменения конфигурации и делает пачкой то, что оператор делал бы неделю.

Живой пример: смена сезона

В интернет-магазине, чью 1С:УТ 11 я сопровождаю, каждый сезон повторяется одна и та же история: лыжные палки «STORM 1 25-26» должны стать «STORM 1 26-27», а реквизит «Год выпуска» — поменяться на «2026/2027». Товаров с сезонной маркировкой — сотни. Руками это несколько дней монотонной правки с гарантированными опечатками.

Обработка решает это так: в таблицу вставляется список карточек — названиями, артикулами или идентификаторами. В шапке задаётся правило «найти → заменить» для наименования и новое значение года. Запуск — и сотни карточек обновлены за один запуск, с отчётом по каждой строке.

Фрагмент кода обработки «Смена сезона номенклатуры» и список готовых .epf Та самая обработка: комментарий в шапке модуля — это и есть её ТЗ и инструкция.

Главный принцип: обработка не угадывает

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

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

Второй принцип — план отката. У той же смены сезона обратная операция симметрична: поменять местами «найти» и «заменить» и прогнать по тому же списку. Поэтому список карточек сохраняется — он и есть кнопка «отменить».

Почему это безопасно для вашей базы

Ни одна моя доработка не запускается сразу на рабочей базе. Порядок такой:

  1. Снимается копия базы (выгрузка .dt или бэкап СУБД).
  2. Копия разворачивается на моём отдельном сервере с копией базы — отдельный сервер 1С + PostgreSQL, заголовок окна начинается с «[КОПИЯ]», перепутать с продом невозможно.
  3. Обработка пишется и проверяется на копии, на реальных данных.
  4. На рабочую базу попадает уже проверенный инструмент — и сначала в режиме «показать, что изменится», потом в рабочей базе.

Для владельца это значит: эксперименты и ошибки разработки случаются на копии, рабочая база их не видит.

Когда пора писать обработку

Простой тест. Если хотя бы два пункта про вас — обработка окупится на первом же запуске:

  • одно и то же действие в базе повторяется больше двадцати раз подряд;
  • оператор возит данные копипастой между Excel и 1С;
  • правка «сезонная»: раз в квартал/сезон её делают заново по тому же сценарию;
  • после ручной серии правок регулярно всплывают опечатки и «потерянные» карточки;
  • выгрузили в Excel → поправили → загрузили обратно руками.

Для масштаба: та же смена сезона руками — несколько дней монотонной работы оператора; обработкой — один запуск плюс десять минут на проверку отчёта. Стоимость обработки «от 1 500 ₽» отбивается за первый же сезон.

Что ещё закрывается обработками

Кроме смены сезона, из того, что я делал для действующего магазина: массовое заполнение реквизитов номенклатуры по внешнему списку, создание карточек по образцу, привязка номенклатуры контрагентов, дамп структуры базы для анализа на уровне SQL. Общий знаменатель один: везде, где оператор повторяет одно действие больше пары десятков раз, дешевле один раз написать инструмент.

Если в вашей 1С есть такая повторяющаяся боль — опишите её своими словами, я скажу, сколько будет стоить её убрать.