Что происходит при обновлении 1С: обновляется ли интеграция автоматически
Один из самых частых технических вопросов при подключении внешней системы к 1С — что произойдёт с интеграцией при обновлении конфигурации. Опасение обоснованное: у многих в опыте есть история, когда обновление 1С «ломало» что-то, что было настроено индивидуально — переставала работать печатная форма, пропадало поле в документе, ломался внешний обмен. Проблема в том, что этот опыт часто обобщают до «1С вообще плохо обновляется», хотя на деле источник риска гораздо конкретнее. Разберёмся, откуда берётся этот риск и когда его на самом деле стоит опасаться.
Как устроено обновление типовых конфигураций 1С
1С регулярно выпускает обновления типовых конфигураций — УТ, УНФ и других: исправления ошибок, новые возможности, изменения в связи с законодательством (например, обновление форматов электронной отчётности или правил маркировки товаров). Платформа 1С:Предприятие умеет обновлять конфигурацию базы данных, объединяя изменения из новой версии с уже накопленными данными — это стандартный, штатный механизм обновления, знакомый любому пользователю 1С.
Пока конфигурация базы остаётся «на поддержке» — то есть её объекты (справочники, документы, регистры) не были изменены вручную относительно типового состояния — обновление проходит по стандартному сценарию без конфликтов: новая версия конфигурации накатывается поверх текущей, а данные, накопленные в базе, остаются на месте.
Откуда берётся риск при обновлении
Риск возникает не из-за самого факта обновления, а из-за того, что было добавлено в конфигурацию сверх типового состояния: дополнительные реквизиты в документах и справочниках, собственные обработки, изменённые формы, встроенный в типовые объекты код. Каждое такое изменение при обновлении нужно вручную сверить с новой версией типовой конфигурации — это называется объединением изменений, и чем больше и сложнее доработки, тем больше ручной работы и риска ошибиться при каждом обновлении.
Именно поэтому многие интеграции, построенные через прямую доработку конфигурации — добавление специальных полей под нужды внешней системы, отдельных обработок обмена, — со временем становятся источником регулярной головной боли: каждое обновление типовой конфигурации превращается в отдельный проект по проверке, что ничего не сломалось.
Есть и более радикальный сценарий — «снятие конфигурации с поддержки»: если изменения в типовые объекты вносились напрямую, без механизма расширений, в какой-то момент штатное обновление через поставщика становится невозможным вообще, и каждое следующее обновление приходится переносить вручную, объект за объектом, силами программиста 1С. Это крайний случай, но он показывает, что риск обновления — это не абстрактная неприятность, а вполне измеримая статья затрат на сопровождение, которая растёт вместе с объёмом доработок.
Как это работает в b2bizi
b2bizi работает на типовых, немодифицированных метаданных 1С:УТ и 1С:УНФ — без добавления новых реквизитов, справочников или обработок в конфигурацию клиента. Портал читает и передаёт данные через стандартные объекты обмена, которые есть в конфигурации «из коробки».
Поскольку в конфигурацию клиента ничего не добавлено, стандартное обновление типовой конфигурации 1С не конфликтует с тем, что использует b2bizi — конфликтовать попросту не с чем: интеграция не меняет структуру базы, только читает и записывает данные через её типовые объекты.
Это прямое следствие того же принципа, на котором построена работа с двумя конфигурациями сразу — 1С:УТ и 1С:УНФ: портал ориентируется на типовой состав объектов конкретной конфигурации, а не на внесённые в неё изменения, поэтому обновление, полностью соответствующее типовому релизу поставщика, не требует ручного вмешательства со стороны интеграции.
Что всё-таки стоит проверить
Это не означает, что можно вообще не думать об обновлениях. Если база клиента уже была ранее доработана кем-то другим — например, добавлены свои поля в документ заказа или изменена типовая обработка проведения, — стоит уточнить у своей ИТ-команды, не затрагивают ли эти доработки именно те объекты, с которыми работает интеграция: номенклатуру, цены, остатки, заказы, контрагентов. Сама по себе доработка в другой части конфигурации на работу b2bizi не влияет, но полную картину состояния базы имеет смысл сверить перед подключением, особенно если база сильно кастомизирована.
Если база клиента уже снята с поддержки или обновляется вручную — само по себе это не мешает работе b2bizi (портал по-прежнему обращается к тем же типовым объектам), но график обновлений в этом случае зависит уже не от релизов поставщика 1С, а от внутреннего процесса клиента, и это стоит учитывать отдельно.
Практический совет для ИТ-специалиста, который впервые оценивает конкретную базу перед подключением: попросить у клиента (или у обслуживающего базу партнёра) короткую справку о том, снята ли конфигурация с поддержки и вносились ли изменения в объекты, связанные с номенклатурой, ценами, остатками, заказами и контрагентами. Если ответ «нет, конфигурация типовая, на поддержке» — риск, связанный с обновлениями, для интеграции, построенной на типовых объектах, можно считать закрытым. Если же выясняется обратное — это не повод отказываться от интеграции, а повод заранее спланировать проверку конкретных объектов перед подключением, вместо того чтобы столкнуться с сюрпризом после первого же обновления.
Итого
Обновление типовой конфигурации 1С само по себе не ломает работающую на её типовых объектах интеграцию — риск создают доработки, добавленные поверх типового состояния. Поскольку b2bizi не вносит изменений в конфигурацию клиента, а работает на её стандартной структуре, штатные обновления 1С проходят независимо от портала. Это тот случай, когда простой ответ — «мы ничего не меняем в вашей базе» — одновременно является и техническим, и самым надёжным решением вопроса про обновления.
Подробнее о том, как устроена интеграция с 1С в самом b2bizi — на странице «Интеграция с 1С». Если хотите посмотреть портал на структуре своего каталога — оставьте заявку на демо.