Что значит «нетиповая конфигурация» простыми словами
Типовая конфигурация - это база, которая соответствует поставке 1С и обновляется стандартным способом. Нетиповая - база, где меняли объекты конфигурации: документы, справочники, отчеты, обработки, регистры, роли или модули.
Для пользователя разница может быть незаметной. Он открывает тот же документ, нажимает те же кнопки и получает привычный результат. Но для обновления разница принципиальная: система должна совместить изменения разработчиков 1С с изменениями, которые когда-то внес программист под ваш бизнес.
Нетиповость не является проблемой сама по себе. Часто именно доработки делают 1С удобной для конкретной компании. Проблема появляется, когда доработки не описаны, давно не проверялись и мешают переходить на актуальные релизы.
Признаки, что база уже не совсем типовая
Самый простой бытовой признак - обновления давно не ставятся автоматически. Администратор или программист говорит, что нужно «сравнение и объединение», «конфигурация снята с поддержки» или «там много изменений».
Еще один признак - в базе есть функции, которых нет в стандартной поставке: особые печатные формы, нестандартные отчеты, автоматическое создание документов, обмен с внешними системами, необычные права пользователей.
Отдельно стоит смотреть внешние обработки и расширения. Они могут быть аккуратным способом доработки, но после обновления их тоже нужно проверять: изменились данные в типовой конфигурации - старая обработка может начать работать иначе.
Что стоит спросить у текущего специалиста:
- снята ли конфигурация с поддержки полностью или частично;
- какие объекты изменены по сравнению с типовой поставкой;
- есть ли расширения, внешние отчеты и обработки;
- есть ли обмены с сайтом, CRM, банком, ЭДО или другими базами;
- есть ли описание доработок и кто может объяснить их назначение.
Почему это важно перед обновлением
Чем больше изменений в базе, тем сложнее оценка. Нельзя честно сказать срок обновления только по названию конфигурации. Две базы «1С:Бухгалтерия» могут отличаться радикально: одна обновляется за вечер, другая требует обследования и переноса доработок.
Если начать обновление без понимания нетиповости, можно получить два неприятных сценария. Первый - обновление технически не проходит. Второй хуже: обновление проходит, но потом выясняется, что часть рабочих процессов сломалась.
Поэтому разумный порядок такой: сначала определить состояние поддержки и список изменений, затем обновить копию, проверить сценарии и только после этого трогать рабочую базу.
Что проверить до обращения к подрядчику
- Название конфигурации и текущий релиз.
- Когда последний раз база успешно обновлялась.
- Есть ли сообщение о снятии с поддержки.
- Какие внешние обработки, отчеты и печатные формы используются каждый месяц.
- Какие обмены критичны для работы компании.
- Кто из пользователей может проверить результат после обновления.
- Есть ли свежая резервная копия.
Таблица для быстрого решения
| Ситуация | Что это значит |
|---|---|
| База обновляется автоматически | Скорее всего, конфигурация близка к типовой, но внешние обработки все равно стоит проверить. |
| Нужны сравнение и объединение | В конфигурации есть изменения, обновление требует специалиста. |
| Релизы не ставились годами | Риск выше: может понадобиться обновление через промежуточные версии. |
| Никто не знает, что дорабатывали | Нужна диагностика и опись рабочих сценариев перед оценкой. |
Когда лучше не тянуть
Обращаться к специалисту стоит не тогда, когда все уже остановилось, а когда появились повторяющиеся симптомы: база давно не обновлялась, пользователи обходят проблему вручную, данные расходятся, один сотрудник хранит всю логику в голове или любое изменение вызывает страх сломать учет.
Нормальный первый шаг не обязывает начинать большой проект. Достаточно описать ситуацию, показать один-два примера и получить понятный маршрут: что проверить, где риск, какая работа действительно нужна.