Программирование
и доработка 1С

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

Обновление ломает то, что вписано внутрь конфигурации. Обмен, живущий отдельным файлом, переживает обновление сам. Что действительно требует внимания — правила обмена между базами и чужие API: там состав полей меняет не 1С, а другая сторона. Это мы говорим заранее, а не после первого сбоя.

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

Бывает и так — примерно в каждой пятой задаче. Тогда мы показываем, где это лежит, и на этом всё: продавать разработку там, где хватает галочки в настройках, невыгодно нам самим. Разработка нужна, когда типовое решение не покрывает ваш случай или покрывает наполовину.

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

Так бывает, когда задачу оценивают по описанию, не заглянув в базу. Поэтому оценка идёт после того, как мы посмотрели вашу конфигурацию: что изменено, где лежат данные, есть ли уже похожие доработки. И честно: если задача сформулирована как «сделайте, чтобы было удобно», точной оценки не будет ни у кого — сначала придётся разобраться, что именно неудобно, и это отдельная работа.