Как отличить настройку 1С от доработки: где заканчивается «покрутили галочки» и начинается код
Привет, это СБиСик. Сейчас расскажу историю, которую я, честно говоря, слышу с таким постоянством, что уже хочется ставить её на фон как офисный шум. «Ну мы же просто настроили 1С, почему после обновления всё поехало?». И вот тут обычно в воздухе зависает очень неудобная пауза. Потому что ответ простой, но неприятный: если что-то сломалось после обновления, значит, это была не настройка. Это была доработка.
И вот тут начинается путаница. Для бухгалтера, менеджера, логиста, даже для руководителя слово «настроили» звучит почти одинаково. Ну подумаешь, поле добавили, кнопку перенесли, печатную форму поправили, отчет сделали поудобнее. Вроде бы мелочь. А для 1С это может быть совсем не мелочь, а вмешательство в код, которое потом надо тащить через обновления как чемодан без ручки: и бросить жалко, и нести тяжело.
Кстати, такие короткие наблюдения из практики я иногда выкладываю быстрее в наш канал в MAX, потому что пока длинный разбор допишешь, уже прилетает новая история от клиента, и снова всё по кругу.
Если совсем по-простому, настройка 1С — это когда вы используете то, что уже есть в программе. Включили опцию, заполнили справочник, поменяли роль доступа, указали параметры учета, добавили колонку из уже существующего поля в отчет. Дом тот же самый. Вы просто переставили мебель, повесили другие шторы, где-то лампу подкрутили. А доработка 1С — это уже когда вы начинаете менять сам дом. Достроили комнату, прорубили окно, перепланировали кухню. Вроде бы жить стало удобнее, но теперь любое обновление — это уже не просто нажать кнопку, а отдельная история с программистом.
И вот тут, кстати, главное правило, которое я бы прям маркером выделил: если изменился код — это доработка. Если код не трогали, а только включили штатный механизм, это настройка. Всё остальное — разговоры вокруг да около. Иногда полезные, иногда очень дорогие, но всё равно разговоры.
Почему «настроили» и «не обновляется» — это обычно одна и та же история
Самый простой способ понять, что у вас было на самом деле, — посмотреть на обновление. Настройка живет спокойно, обновление ей не страшно. Ну, почти как табличка на двери: её можно переклеить, а можно оставить, и при переезде она не развалится. Параметры, права, справочники, остатки, классификаторы — всё это обычно переживает обновление нормально. А вот если кто-то полез в код, поменял форму, модуль, печать, алгоритм расчета или обмен — там уже другая песня.
И песня, если честно, не очень веселая. Потому что типовая конфигурация 1С обновляется как задумано разработчиком. А доработки, если они сделаны поверх типовой конфигурации, надо переносить. То есть программист после обновления ещё раз пробегает по изменениям, сравнивает, переносит, проверяет, не сломалось ли что-то в соседнем месте. И вот за это бизнес обычно не любит платить, хотя именно за это и платит. Просто не сразу, а потом, когда «неожиданно» выясняется, что отчет уже не открывается, печатная форма уехала, а обмен с сайтом помолчал, подумал и умер.
Тут есть тонкий момент, который часто теряется в разговоре. Люди думают: «Если я не вижу кода, значит, кода и нет». А нет, не так. Иногда доработка спрятана в печатной форме, в внешней обработке, в расширении, в обработчике события, в собственном алгоритме обмена. Пользователь видит только результат: кнопку, поле, красивый отчет. А под капотом уже работает программистская логика. И именно поэтому фраза «мы ничего не ломали, просто настроили» у 1С вызывает лёгкую, очень вежливую тоску.
Если интересно, вторая половина этой истории обычно всплывает уже в коротких заметках и разборе живых кейсов в Telegram-канале, потому что там удобно разбирать именно такие штуки: один вопрос, один ответ, без длинного входа, зато с нормальной практикой.
Где проходит граница между настройкой и доработкой
Давайте без философии, а по рабочему. Настройка — это когда вы меняете параметры работы программы. Доработка — когда вы меняете логику работы программы. Звучит почти одинаково, но это как «поменял режим света» и «перепаял проводку». В быту похоже, в учете — совсем нет.
Например, вы хотите, чтобы в документе были включены определенные виды учета, чтобы пользователю были доступны нужные роли, чтобы в отчете добавились уже существующие реквизиты, чтобы на предприятии загрузились остатки, чтобы классификатор заполнился автоматически. Это все настройки. Да, иногда руками. Да, иногда долго. Но это работа с тем, что уже предусмотрено конфигурацией.
А вот если вам нужно добавить новый реквизит, которого в системе нет, изменить формулу расчета, внедрить новый порядок согласования, сделать свою печатную форму, завести обмен с CRM, маркетплейсом или сайтом, написать новый отчет с собственной логикой отбора — это уже доработка. Тут не получится отделаться фразой «ну вы же там что-то в 1С просто нажимаете». Нет, не нажимаем. Тут уже пишем, проверяем, тестируем и потом ещё молимся, чтобы обновление не подкинуло сюрприз.
Причем самое смешное, что многие «мелочи» на практике оказываются не такими уж мелкими. Вот, например, бухгалтер говорит: «Нам бы в счет-фактуру добавить одно поле, там совсем чуть-чуть». А потом выясняется, что это поле надо хранить, выводить, проверять, чтобы оно не ломало печать, чтобы оно попадало в обмен, чтобы не конфликтовало с формой. И маленькая просьба превращается в нормальную доработку. Не потому что кто-то жадный. Просто потому что так устроена архитектура.
И да, есть ещё один коварный момент: люди часто ориентируются на интерфейс. Мол, если я поменял что-то в форме, значит, это настройка. Но форма — это не просто картинка. Это часть логики. Иногда даже перенос одной колонки в отчете уже тянет за собой изменение структуры. Иногда нет, иногда да. И вот здесь как раз нужен живой анализ, а не угадайка.
Что точно считается настройкой, а что уже пахнет кодом
Сейчас сделаю простую шпаргалку, без канцелярита. Если вы:
— включили или отключили функциональную опцию;
— заполнили справочник;
— назначили права доступа через роли;
— изменили параметры учета;
— настроили отбор в стандартном отчете;
— загрузили остатки или классификатор;
то это, как правило, настройка. Не всегда быстрая, не всегда приятная, но всё-таки настройка.
А если вы:
— добавляете новое поле, которого не было;
— меняете печатную форму;
— пишете новый алгоритм расчета;
— создаете свой отчет с собственной логикой;
— подключаете API к CRM, сайту или маркетплейсу;
— делаете автоматическую обработку по своему сценарию;
то это доработка. И тут уже не надо делать вид, что это «чуть-чуть настроили». Это программирование, просто часто оно выглядит приличнее и тихо сидит в интерфейсе.
И вот ещё важная штука: в базовой версии 1С доработка невозможна. Вообще. Не «сложно», не «дороже», а именно невозможно в рамках лицензии. Базовая версия для настройки — пожалуйста, для изменения конфигурации — нет. И это тот случай, когда спорить с документацией бессмысленно. Можно сколько угодно говорить «ну нам только одну штучку добавить», но если речь про изменение кода, то тут уже нужна не хитрость, а другая версия продукта.
Вот поэтому, когда клиент приходит и говорит: «А что у нас там такого сложного, просто поле добавить», я всегда сначала спрашиваю: а где именно это поле должно жить, куда попадать, кто его будет видеть, и должно ли оно переживать обновление. Потому что иногда ответ занимает три минуты. А иногда после него становится понятно, что это не поле, а целый мини-проект.
И, если честно, именно на этом месте чаще всего и теряются деньги. Заказали как настройку, а по факту нужна была доработка. Исполнитель, чтобы не отпугнуть, сказал мягко: «Да это мы настроим». А потом начинается неловкое уточнение бюджета, потому что «настроить» внезапно оказалось «написать, проверить, перенести, протестировать». Ну, вы понимаете.
Дальше я покажу пару живых ситуаций, где разница видна вообще без лупы, и там уже будет совсем просто отличить одно от другого.
Где теряют деньги: как путаница между настройкой и доработкой приводит к потерям
Рассмотрим пример, когда бизнес решает «настроить» печатную форму счета. Бухгалтер говорит: «Нам нужно добавить поле с адресом». В голове у руководителя возникает картина простой манипуляции: постучались в 1С, нажали на несколько кнопок, и вот, чудо — нужное поле на месте. А реальность такова: на самом деле это была серьезная доработка. Теперь необходим код для хранения нового значения, проверки, сохранения, и, возможно, даже интеграция с другими документами.
Проблема возникает, когда заказчик не осознает, что эта «проста», на первый взгляд, операция требует времени и навыков программиста. Результат: бухгалтер радуется новому полю, но при обновлении системы появляются ошибки, формула перестает срабатывать, и вся работа с печатной формой оказывается под угрозой. К сожалению, многие компании сталкиваются с этой «потерей» функционала, просто не понимая, что ею обусловлены дополнительные затраты.
Ошибки, которые приводят к недопониманию
Изучая реальные ситуации, я часто вижу, как даже опытные пользователи 1С иногда допускают ряд ошибок. Например, клиент приходит с запросом: «Нам нужно сделать такой отчет, чтобы он показывал только определенные данные». На первый взгляд, это звучит как настройка. Заказчик думает, что просто нужно открыть фильтры. Однако добавление дополнительных расчетов, создание новых колонок и реализация уникальных алгоритмов сводит авторизацию к доработке. И это, к сожалению, чаще всего не учитывается на стадии проектирования.
Я часто сталкиваюсь с заблуждением: «Если мы можем сделать это сами, значит, это настройка». Но, как показывает практика, даже мелкие изменения могут требовать кодирования. Если вы добавляете новые условия, которые отсутствуют в стандартной конфигурации, вы уже говорите о доработке. Мягкое и безопасное решение — не облегчать задачу, стараясь классифицировать изменения как «нечто простое».
Практические наблюдения из работы с клиентами
Разберем более глубокий пример из практики: одна компания решила «настроить» интеграцию с CRM-системой. Бухгалтеры обратились и сказали, что это просто: они чуть-чуть скорректируют параметры обмена. Но по факту, когда дело дошло до реализации, выяснили, что нужно писать API, настраивать обработчики обмена и контролировать, как данные синхронизируются.
Конечно, всё это оказалось доработкой. Благая весть: при правильном подходе, это можно будет сделать через механизм расширений. Это минимизирует риски, но всё же подразумевает программистские навыки, понимание кода и логики работы системы.
Что делать, чтобы не платить дважды
Зная все эти моменты, важно понять одно: общайтесь с исполнителем правильно. «Что конкретно меняется в коде?», «Нужно ли это будет переносить после обновления?» — такие вопросы помогут вам избежать неприятностей с обновлениями в будущем. Убедитесь, что четко обозначены все этапы работ, а терминология понятна и однозначна.
И вот, подводя итог, советы для бизнеса: держите под контролем планирование работ, пресекайте избегание рисков, ярым образом акцентируя внимание на изменениях в коде. Если у вас возникает какая-то «визы»-ослепляющая смесь между настройкой и доработкой, всегда пишите грамотный план изменений для разработчиков — и проверяйте их выполнение заранее.
Как заметил один из моих клиентов: «Научившись различать настройку и доработку, я, кажется, научился и не терять деньги». Не правда ли, вот в этом и смысл? Хотите обсудить свою ситуацию? Пишите, всегда открыт для диалога!