почему доработка 1С ломается после обновления и как наладить сопровождение
Сопровождение и разработка 1С — это регулярная работа программиста и администратора с уже работающей базой: устранение ошибок, доработка под новые задачи бизнеса и синхронизация правок с обновлениями платформы. Без регламента доработки конфликтуют с обновлениями, документы перестают проводиться, а закрытие месяца превращается в аврал бухгалтерии.
почему возникает ошибка при проведении документов после доработки 1С
В пятницу вечером, перед сдачей квартального отчёта, главный бухгалтер закрывает месяц в 1С:Бухгалтерии. Документ реализации, который проводился без единого сбоя ещё вчера, теперь выдаёт ошибку «обработчик не найден», и весь пакет закрывающих операций останавливается на середине. За два дня до этого системный администратор поставил плановое обновление платформы до свежего релиза, а в базе тем временем давно жила доработка: кастомный отчёт по остаткам на складах, который программист написал ещё весной под прежнюю версию конфигурации, и печатная форма счёта, добавленная другим подрядчиком год назад.
Само обновление доработку напрямую не трогало — но конфликт всё равно случился: кастомный код обращался к процедуре, которую в новом релизе переименовали, а печатная форма ссылалась на реквизит, которого в обновлённой структуре справочника контрагентов больше нет. Так выглядит типичная причина подобного сбоя. Правку делают один раз, подписывают акт и забывают про неё, а типовая конфигурация тем временем продолжает жить своей жизнью и обновляться без оглядки на чужой код. Чем больше в базе накопленных доработок — печатные формы, дополнительные обработки, изменённые роли доступа, самописные регламентные задания, — тем выше шанс, что очередной релиз заденет хотя бы одну из них.
Ставка здесь не абстрактная. Если ошибка всплывает в день сдачи отчётности, бухгалтерия срывает срок и получает вопросы от налоговой инспекции или банка, где обслуживается расчётный счёт. Если ломается модуль расчёта зарплаты — задерживается выплата сотрудникам, а это уже не только репутационные издержки, но и прямой финансовый риск. Кроме прямых потерь, компания тратит время программиста на разбор проблемы в самый неподходящий момент — по срочному тарифу, а не по плану, что почти всегда дороже спокойной профилактики.
как исправить конфликт доработки с обновлением конфигурации
Первое правило — не чинить конфликт на боевой базе, где в это время продолжает работать бухгалтерия. Разворачиваем копию базы на тестовом сервере и через конфигуратор сравниваем изменённые модули с типовым релизом: платформа 1С показывает построчно, где именно доработанный код разошёлся с эталонной конфигурацией. Это быстрее, чем гадать по логам, и безопаснее, чем экспериментировать на живых данных: если правка окажется неудачной, откатить тестовую копию можно за минуты, а откатить боевую базу в разгар рабочего дня — уже нет.
если дело в коде
Когда расхождение найдено, доработку переписывают под структуру нового релиза, а не откатывают обновление платформы назад. Откат снимает симптом на день-два, но оставляет базу без свежих правок безопасности, обновлённых форм регламентированной отчётности и исправлений, которые 1С выпустила вместе с этим релизом не просто так. Через месяц обновление всё равно придётся ставить, и тот же конфликт повторится в тот же неудобный момент — например, снова в день закрытия периода. Разумнее сразу привести код доработки в соответствие с новой структурой конфигурации и зафиксировать это в описании доработки.
если дело в железе
Если после сравнения кода расхождений нет, а документы просто медленно проводятся и база в целом тормозит после обновления, причина может быть не в правках, а в сервере: выросла нагрузка на процессы платформы, а вычислительных мощностей осталось столько же, сколько было полгода назад. Проверить это в цифрах, а не на глаз, помогает тест Гилёва — методика, которую используют для замера производительности связки сервер и база на конкретном железе. Если результат теста низкий даже на чистой типовой конфигурации без доработок, дальше оптимизировать код бессмысленно: нужно обновить платформу и перенести базу на сервер с запасом по ресурсам, а не откатывать релиз каждый месяц в надежде, что само пройдёт.
что делать, если ошибка повторяется после каждого обновления
Если один и тот же класс ошибок всплывает после каждого релиза подряд, дело не в конкретной правке, а в процессе вокруг неё. Чаще всего у компании просто нет тестовой базы: обновление ставят сразу на рабочую копию поздно вечером или в выходные, и первым проблему обнаруживает не программист заранее, а бухгалтер посреди отчётного дня, когда откатывать уже поздно. Второй частый сценарий — доработки за несколько лет делали разные подрядчики без единой документации, и новый исполнитель тратит целый день на то, чтобы разобраться в чужом коде, прежде чем вообще приступить к исправлению.
Решение здесь — не искать программиста, который чинит быстрее остальных, а выстроить процесс вокруг доработок. Нужен тестовый контур, куда любое обновление ставится первым и куда переносят все доработки перед выкладкой на боевую базу. Нужен журнал изменений с описанием, что, когда и зачем поменяли, — без него каждая новая правка начинается с археологии в коде. И нужен один постоянный исполнитель доработки 1С, который ведёт базу на регулярной основе, знает историю правок и логику бизнеса заказчика, а не тушит симптомы разово по обращению. При таком процессе конфликт находят на тестовом контуре за час работы, а не на боевой базе в разгар отчётной кампании.
как предотвратить сбои при доработке и обновлении 1С
Регламент сопровождения снимает большинство подобных сбоев ещё до того, как они долетят до бухгалтерии. Рабочая схема для компании из Москвы с одной базой и бухгалтерией от пяти-шести человек обычно строится на нескольких простых правилах:
- ✓обновления сначала ставят на тестовую копию базы за несколько дней до выкладки на боевую, а не в день выхода релиза от 1С — так есть время найти конфликт спокойно, а не в аврале;
- ✓каждую доработку фиксируют в журнале с датой, автором и причиной изменения — это экономит часы работы при следующем конфликте и избавляет от повторного разбора уже решённой задачи;
- ✓резервную копию снимают перед каждым обновлением и перед каждой крупной доработкой, а не только по общему расписанию раз в неделю;
- ✓за базой закреплён администратор, который следит за нагрузкой на сервер и расширяет ресурсы заранее, а не после первых жалоб пользователей на медленную работу.
Отдельный случай — когда доработок в типовой конфигурации накапливается так много, что каждое обновление 1С превращается в отдельный проект с рисками для бизнеса. Это обычно означает, что компания переросла типовую 1С:Управление торговлей или бухгалтерию, и держать десятки кастомных обработок в старой конфигурации выходит дороже и рискованнее, чем перейти на 1С:ERP с нужной функциональностью из коробки. Часть накопленных доработок в этом случае просто перестаёт быть нужна, а вместе с ней исчезает источник половины будущих конфликтов при обновлении.
сколько стоит сопровождение и разработка 1С в Москве
Стоимость зависит от формата работы, а не от разовой цены за одну правку: почасовая ставка начинается от 3800 ₽ в час, а аренда сервера — от 1100 ₽ в месяц за пользователя. У нас в Москве сопровождение и разработка 1С считаются так:
| Формат работы | Что входит | Стоимость | Кому подходит |
|---|---|---|---|
| Разовая правка ошибки | программист чинит конкретный сбой по обращению клиента | от 3800 ₽/час | компаниям без регулярных доработок |
| Абонентское сопровождение | мониторинг базы, тестовый контур, приоритетная очередь заявок | считается по объёму, ставка от 3800 ₽/час | компаниям с активными доработками и частыми обновлениями |
| Администрирование сервера 1С | сисадмин следит за нагрузкой, бэкапами, обновлением платформы | от 3800 ₽/час на администрирование, аренда сервера от 1100 ₽/мес за пользователя | компаниям без своего сервера или на устаревшем железе |
| Разработка новой доработки | техзадание, код, тестирование на копии базы перед выкладкой | считается по объёму задачи | компаниям, расширяющим функциональность базы |
Если база регулярно виснет при закрытии месяца или при загрузке отчёта — а не только сразу после доработок и обновлений, — дело может быть в мощности сервера, и тогда правки в конфигурации саму скорость не спасут. В этом случае разумнее сразу оценить внедрение 1С на подходящей инфраструктуре, чем годами латать конфигурацию, которая с каждым релизом упирается в железо всё сильнее. Мы забираем сопровождение целиком: разбор конкретной ошибки в проведении документа, администрирование сервера, написание новых доработок — чтобы не искать отдельного подрядчика на каждую следующую проблему.
❓ Частые вопросы
В чём разница между доработкой 1С и сопровождением 1С?
Доработка — разовая работа программиста, которая добавляет в базу новую функциональность: отчёт, обработку, печатную форму. Сопровождение — постоянный процесс: мониторинг ошибок, тестирование перед обновлениями, поддержка уже написанных доработок. Компании обычно заказывают доработку один раз, а сопровождение — на регулярной основе, чтобы правки не ломались при обновлении конфигурации.
Сколько стоит час работы программиста 1С в Москве?
Сопровождение и разовая работа программиста 1С стоят от 3800 ₽ за час. Итоговая стоимость зависит от сложности задачи: правка мелкой ошибки в печатной форме занимает меньше времени, чем разбор конфликта доработки с обновлением платформы или написание нового отчёта с нуля.
Можно ли обновлять 1С, если в базе много доработок?
Можно, но обновление сначала ставят на тестовую копию базы, а не на рабочую. Так видно, какие доработки конфликтуют с новым релизом, ещё до того, как ошибка попадёт к бухгалтеру. Без тестового контура каждое обновление превращается в риск остановки проведения документов в день закрытия месяца.
Что делать, если старый подрядчик пропал, а база всё ещё на его доработках?
Новый программист изучает код через конфигуратор и журнал регистрации, даже без документации от прежнего подрядчика. Это дольше, чем работа по готовому техзаданию, но решаемо. После разбора имеет смысл завести журнал изменений, чтобы следующая передача базы не начиналась с нуля.
Как понять, что база тормозит из-за железа, а не из-за доработок?
Показательный тест — тест Гилёва, который измеряет производительность связки сервер и база в цифрах. Если результат низкий даже на чистой типовой конфигурации без доработок, дело в сервере, и правки в коде не помогут — нужен более мощный сервер под нагрузку.
Или позвоните: +7 906 045-28-27 — в рабочее время с 9:00 до 19:00
Остались вопросы? Нужна помощь?
Менеджеры компании с радостью ответят на ваши вопросы, произведут расчет стоимости услуг и подготовят индивидуальное коммерческое предложение.
Бесплатная консультация

