Типовая БУХа + свои доработки: подружил через расширение и спокойно обновил

Предыстория: как клиент ко мне пришёл

Осенью 2024 года я выпустил расширение для Бухгалтерии, которое позволяло на старых релизах печатать актуальную форму УПД без обновления конфигурации. После публикации мне стали писать люди с похожей болью: “релиз старый, обновляться страшно/муторно, но жить дальше так нельзя”.

Один из них Юрий — предприниматель с небольшим логистическим бизнесом. Несколько лет назад он уже обновлялся вручную “через боль” и повторять не хотел. Но обновилась форма УПД, впереди маячили возможные другие законодательные инициативы

Запрос был простой и взрослый:
вынести самописку в расширение и обновить БП до актуального релиза, при этом не сломать обмен с двумя базами бухгалтеров.

Вводные проекта

Ситуация классическая: небольшой бизнес, файловая 1С:Бухгалтерия, база размером меньше 30 ГБ. Внутри конфигурации за несколько лет накопились доработки — владелец сам(не будучи профессиональным 1С-разработчиком, по видеокурсам) дописал себе мини-подсистему под свои бизнес-процессы. Разумеется, местами безжалостно правились типовые объекты/формы.

Параллельно работал обмен с двумя базами бухгалтеров на КД2.

Обновление откладывали не из-за “страшно”, а из-за комбинации факторов:

• самописка внутри конфигурации → любое сравнение/объединение превращается в ручной разбор, долгий и опсный;
• обмены → риск “починил одно — сломал цепочку”;
• на горизонте накопились изменения типовой БП, из-за которых тянуть дальше стало невозможно
• обновляться самостоятельно просто дороже.

Цель проекта в одном предложении:

«Чтобы было хорошо, и всё работало как раньше»,

а задача соответственно:

обновить БП с 3.0.103.21 до последней актуальной(на момент обновления непосредственно релиз 3.0.173.31) так, чтобы самописный блок остался рабочим, данные не потерялись, а КД2-обмен с бухгалтерами продолжил работать.

Почему “вынести код в расширение” — это только половина работы

Переезд в расширение начинающие программисты 1С обычно воспринимают как задачу про код: “перенёс модули/формы/код — готово”. На практике самое рискованное место — данные и связи, которые годами жили в реквизитах/табличных частях/регистрах “самописного блока”.

Если код переехал, а данные переехали криво — внешне “всё запускается”, но бизнес-процессы начинают тихо ломаться через неделю (или после первого обмена).

Поэтому я сразу строил проект вокруг связки:

копия → отладка → контрольные проверки → повтор на боевой в согласованное окно → контрольные проверки.

План работ (как я его раскладывал по этапам)

1. Инвентаризация доработок на текущем релизе: что менялось, где зависимостей больше всего, какие объекты точно придётся переносить в расширение.
   Это то, что люди часто не делают – и зря.
2. Вынос самописного блока в расширение на исходной версии клиента (ещё до обновления).
   Не забывайте, что если доработки не задокументированы, то часть из них могут работать совсем не так, как вам заявляют. Мне пришлось потратить дополнительное время на то, чтобы вникнуть в код и в то, что он на самом деле делает. И это нормально: человеческая память не совершенна, мы все иногда что-то забываем.
3. Перенос данных из объектов конфигурации в объекты расширения (отдельный этап).
   Здесь, как и всегда, важно помнить: то, что «должно» работать из коробки, на деле не всегда работает.
4. Обновление типовой БП 3.0.103.21 → 3.0.173.31.
5. Адаптация расширения под новый релиз.
6. Обновление баз у бухгалтеров до аналогичных версий.
   Здесь оказалось, что правки типовой БП у бухгалтеров были, пусть и небольшие.
7. Доработка правил КД2 под новую схему, с расширением и новыми объектами.
8. Прогон контрольных сценариев и тестовых обменов на копиях.
9. Повтор на боевых базах в согласованное окно, с бэкапом и планом отката.
   Также пришлось обновить платформу одному из бухгалтеров, но это мелочи. Главное, учитывайте это.

Четыре грабли, которые съели больше всего внимания

1) Перенос данных из конфигурации в расширение (самая “грязная” часть)

Код перенести относительно прямолинейно. А вот “перелить” реальные данные так, чтобы не потерять историю и ссылки — это отдельная инженерная задача.

Изначально, я планировал использовать готовое решение(//infostart.ru/1c/tools/1304175/). Но при 1-й попытке применения ещё в копии, я столкнулся с ошибкой, которую быстро побороть не смог. Так что решил попробовать написать самописное решение под задачу. Что, разумеется, оказалось ошибкой.

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

Также критичный момент всплыл на регистрах сведений:
регистры оказались раздутыми — много дублей/лишних записей. Если тащить как есть, получаем:

• мусор в новой структуре;
• дальнейший рост объёма базы;
• кратный рост времени переноса и проверки;
• и самое плохое: неочевидные расхождения в логике (когда дубль “случайно выигрывает” по отбору).

Поэтому перед переносом пришлось схлопывать дубли (по ключевым измерениям/периоду/ресурсам — в зависимости от смысла регистра), а уже потом переносить “нормализованный” набор.

Практический вывод: перенос данных — это не “промежуточный пункт”, а отдельный этап со своей подготовкой и тестированием.

2) Отличия реального состояния от названного или «обозначенного»

Классическое «Карта не равно территория». Перед началом работ я, разумеется, провёл аудит предполагаемых работ: посмотрел объём доработок, проверил некоторые взаимосвязи, обсудил с «разработчиком» логику работы и разны нюансы. Причём, потратил на это несколько оплаченных часов.

Но даже так я столкнулся с неожиданностями, и не один раз. Из-за них, к сожалению, даже ЗНАЧИТЕЛЬНО вырос объём работ, из-за чего я даже вынужденно поднял первоначальный ценник, за что мне до сих пор несколько стыдно. В то же время, если бы я этого не сделал, то вряд ли бы продолжил работать с Юрием. И сейчас я понимаю, что пусть это и было тяжёлым и вынужденным, но правильным «взрослым» решением. Спасибо здесь Юрию за понимание.

Вывод: если вы разработчик или бизнес, всегда учитывайте это заранее. Лучше пусть это сразу будет учтено в работе и в ценнике, оговорено заранее. Чтобы в случае неожиданных проблем они были пусть и не предсказаны, но учтены. Это сэкономит всем и деньги, и нервы.

3) Ошибка на боевой базе, которой не было на копии

Как обычно «План действий никогда не идёт по плану действий». Когда схема отработала на копии, при первом обновлении на боевой вылезла ошибка, которая на тестовом стенде не проявлялась.

Решение было стандартное, но важное:

• бэкап перед обновлением и после переноса данных;
• “Тестирование и исправление”;
• повторная проверка ключевых сценариев (до/после);
• и только после этого — продолжение работ.

Вывод: копия обязательна, но не гарантирует 100% идентичности боевой среде. В план надо закладывать “неожиданность прода” как норму, а не как форс-мажор. Всякое бывает…

4) Фактор железа: простои выросли из-за более слабого оборудования у заказчика и бухгалтеров

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

• простой у заказчика: около 4 часов
• простой у бухгалтера: около 3 часов

Это не “поломка”, а физика: файловая база + объёмы + скорость диска/CPU.
Если заранее не учесть железо — можно попасть в ситуацию, когда “по плану 2 часа, по факту 5”.

Что получилось в итоге (было → стало)

Было

• 1С:Бухгалтерия 3.0.103.21
• самописный блок внутри конфигурации
• обмен с 2 бухбазами на КД2
• обновление возможно, но каждый раз как отдельный мини-проект

Стало

• 1С:Бухгалтерия 3.0.173.31
• самописный блок вынесен в расширение
• данные перенесены (в т.ч. приведены в порядок “распухшие” регистры)
• КД2-обмен с двумя бухбазами сохранён и проверен
• дальнейшие обновления становятся заметно предсказуемее: типовая часть меньше “перепилена”

Контрольные точки, которые реально спасают (мини-чек-лист)

Перед стартом

• Бэкап(ы) + понятный план отката (включая “что делаем, если упали на середине”).
• Инвентаризация: список изменённых объектов и зависимостей (хотя бы грубо).
• Оценка железа (особенно если файловые базы и обмены).

После переноса данных

• Сверка “что должно быть” vs “что стало”:
  • контрольные выборки по ключевым справочникам/документам;
  • контрольные запросы по регистрами (объём/уникальность ключей/аномалии);
  • ручная проверка 3–5 реальных сценариев пользователя (не “открылась форма”, а “прошёл процесс”).

После обновления БП

• Проверка ключевых процессов (проведение/печать/закрытие периода — по тому, что критично именно этому бизнесу).
• Проверка расширения: нет ли “тонких” зависимостей от типовых модулей/форм, которые поменялись в новом релизе.

По КД2-обмену

• Тестовый обмен на копиях.
• Прогон цепочки “туда-обратно” на небольшом интервале данных.
• Сверка контрольных документов/сумм (по тому, что бизнес реально сверяет).

Финальные выводы

1. В подобных проектах главный риск — данные, а не код. Перенос планируйте как отдельный этап со своими тестами и “санитарной обработкой” (дубли, мусор, аномалии).
2. Если есть КД2/обмены — это не “хвост”, а часть ядра проекта: цепочку надо проверять заранее и на копиях.
3. Копия обязательна, но планируйте “неожиданность боевой” как норму: проверка/исправление/повторный прогон.
4. Производительность на стенде ≠ производительность у заказчика. Окна простоя считайте с запасом и учитывайте железо.

Послесловие

Я вспомнил этот кейс по нескольким причинам. Потому что совсем недавно делал повторное обновление Юрию, быстрое и дешёвое, прошедшее без проблем. Потому что на многое, что я делал в этом проекте и что делаю обычно в найме, я слышал «да нафиг оно надо, это лишнее время» - как от фрилансеров, так и от программистов из франчей, у кого опыт на  10-15 лет больше моего. Потому что недавно услышал подобное от знакомого руководителя it-отдела в одной немаленькой компании. И удивился, что люди не понимают «очевидных» вещей, которые не столь очевидны, судя по всему.

Огромное спасибо Юрию за то, что он в меня поверил. И что несмотря на все трудности, мы продолжаем работать. Огромное спасибо моей девушке Маше за то, что она посоветовала мне написать эту статью.

Отдельная благодарность автору //infostart.ru/1c/tools/1304175/, Кириллу Трофимову. Кстати, возможно проверю исправлена ли в текущей версии ошибка, с которой я столкнулся в этом кейсе.

Вопросы — в комментарии

Если у вас был похожий опыт (особенно с переносом данных в новые объекты и схлопыванием дублей в регистрах) — интересно сравнить подходы и грабли: у кого что “стреляло” чаще.