«А в конфигурацию вы полезете?» Этот вопрос задают на первом же созвоне, и задает его обычно тот, кому уже один раз полезли. База уехала с поддержки, и теперь каждый релиз регламентированной отчетности стоит двух дней сравнения-объединения и ночи на тестовой копии. Вопрос звучит про технологию, но спрашивают про цену следующих трех лет.
Отвечаю сразу: в типовую лезть почти никогда не требуется; редкие исключения перечислены ближе к концу. Ниже — три способа связать внешний ИИ-сервис с 1С, честные минусы каждого, что именно отваливается на обновлении, как делятся работы между подрядчиком и вашим 1С-ником и чек-лист, который стоит заполнить до первого звонка.
Снятие с поддержки: за что платят потом годами
Типовая конфигурация приходит от вендора на поддержке. Платформа держит рядом эталон — конфигурацию поставщика — и обновление работает как сравнение вашей конфигурации с новым эталоном. Пока вы ничего не меняли, обновление накатывается почти без участия человека.
Дальше три состояния, они видны по каждому объекту в настройке поддержки.
- Объект поставщика не редактируется. Замок закрыт, изменения вендора приезжают автоматически.
- Редактируется с сохранением поддержки. Замок открыт. Каждое обновление превращается в трехстороннее объединение: платформа показывает, что поменял вендор и что поменяли вы, а решение по каждому конфликту принимает человек.
- Снят с поддержки. Обновления по объекту не приезжают вообще. Изменения вендора вы переносите руками, если вообще о них узнаете.
Второе состояние опаснее третьего, потому что выглядит безобидно. Сорок ваших строк внутри типового модуля на три тысячи строк никуда не денутся — их будут проверять глазами при каждом релизе, и делать это будет человек, который эти сорок строк не писал.
Цена решения считается на салфетке. Возьмите число обновлений за прошлый год из журнала, среднее время на объединение и стоимость часа вашего 1С-ника. Двенадцать обновлений по шесть часов при ставке 2500 ₽ дают 180 000 ₽ в год — за право держать сорок строк в чужом модуле. Подставьте свои три числа. В коммерческом предложении этой строки не будет: она проходит по бюджету вашей ИТ-службы и всплывает через год.
Три способа связать ИИ и 1С
Все рабочие схемы устроены одинаково: модель и логика живут во внешнем сервисе, в базе остается коннектор. Отличаются они тем, как именно сервис и база разговаривают. В таблице их пять: три основных способа и две крайние строки для сравнения — штатный OData, которому ниже отведен отдельный раздел, и прямая доработка типовой.
| Способ | Что появляется в базе | Что нужно на стороне 1С | Где болит |
|---|---|---|---|
| Штатный OData | Ничего, только публикация | Веб-сервер, список опубликованных объектов, служебная учетная запись | Отдает объекты как есть, без бизнес-логики; состав почти всегда неполный |
| Внешняя обработка | Элемент справочника дополнительных обработок | Механизм дополнительных отчетов и обработок БСП, права на запуск | Запуск по расписанию, небезопасный режим, версия живет файлом |
| HTTP-сервис в расширении | Расширение рядом с типовой, сама типовая цела | Публикация на веб-сервере, HTTPS, контроль применимости | После обновления расширение может отключиться, публикацию надо повторять |
| Промежуточное хранилище | Регламентное задание или обработка выгрузки | Место под пакеты, транспорт, мониторинг очереди | Задержка, расхождение состояний, обратная запись все равно нужна |
| Правка типовой | Изменения в объектах поставщика | Конфигуратор, хранилище, регламент релизов | Снятие с поддержки, ручное объединение на каждом обновлении |
Способ 1. Внешняя обработка
Файл обработки подключается в справочник дополнительных отчетов и обработок. Метаданные при этом не меняются, конфигурация остается нетронутой, отключается все галочкой. Обработка умеет ходить в ваш сервис по HTTP, разбирать ответ и создавать документы штатными средствами платформы.
Где болит. Обработку кто-то должен запускать: руками из формы либо по расписанию регламентным заданием, и в файловом варианте базы регламентные задания живут только пока открыт сеанс. Внешние обработки исполняются вне безопасного режима, поэтому служба безопасности справедливо задает вопросы про профили и подписи. И третье, бытовое: версия обработки живет файлом, через год у вас три похожих файла и никто не помнит, какой в бою. Лечится тем, что файл хранится в одном репозитории с сервисом, а в справочнике проставляется версия.
Сильная роль этого способа — пилот. Первые недели, когда надо доказать, что модель попадает в ваши документы, обходятся без публикации веб-сервера и без единого нового объекта метаданных. На потоке первички это выглядит так, как описано в разборе распознавания первичных документов в 1С: обработка забирает пачку, сервис возвращает разобранные поля, документы создаются черновиками.
Способ 2. HTTP-сервис в расширении
Расширение лежит рядом с типовой и не меняет ее объекты. Внутри расширения делается свой HTTP-сервис: два-три метода, JSON на входе и выходе, свои коды ошибок. Контракт обмена целиком ваш: наружу уходят ровно те поля, которые нужны задаче, остальные реквизиты документа базу не покидают.
Это самый управляемый вариант для промышленной эксплуатации. Требований на стороне клиента три: опубликованный веб-сервер, сертификат для HTTPS и служебная учетная запись с урезанными правами. Права заслуживают отдельного разговора, он есть в разборе ИИ-агента с правом записи в 1С; здесь достаточно правила «сервис ходит под своей учетной записью, а не под администратором».
Минус честный: расширение — тоже объект метаданных. При обновлении типовой платформа проверяет применимость, и если заимствованный объект изменился, расширение отключается. Для пользователя это происходит молча: кнопки на месте, обмен встал. Как это ловить — ниже отдельным разделом.
Способ 3. Обмен через промежуточное хранилище
1С выгружает пакет — файл, таблицу в отдельной базе, сообщение в очереди. Сервис забирает пакет, обрабатывает, кладет результат обратно. Синхронного вызова нет вообще, стороны не знают друг о друге ничего, кроме формата.
Плюсы серьезные. Сервис может лежать час — учетная система этого не заметит. Нагрузка на базу управляется окном выгрузки. Стартовать можно вообще без доступа в базу: первые недели работают на обычных выгрузках, которые ваш 1С-ник делает руками, и это снимает половину разговоров с безопасностью.
Минусы тоже понятные: задержка от минут до суток, состояние живет в двух местах и рано или поздно расходится, а обратная запись в базу все равно потребует одного из первых двух способов. Для сценариев, где данные нужны непрерывным потоком, схема выглядит иначе — про потоковую выдачу изменений есть отдельный разбор CDC из 1С в реальном времени.
Штатный OData закрывает чтение и упирается в запись
Публикация REST-интерфейса — это галочка в конфигураторе и список объектов, которые вы решили отдать наружу. Читать справочники, документы и регистры можно в тот же день, писать код в базе не надо.
Три ограничения, из-за которых на одном OData проект не собирается. Первое: состав определяется тем, что реально опубликовано, и в базах с историей опубликована обычно половина нужного. Второе: интерфейс отдает объекты без бизнес-логики, запись документа через него не равна проведению со всеми движениями. Третье: тяжелые выборки идут по рабочей базе и конкурируют с закрытием месяца.
Отсюда практическое правило: OData хорош на чтение справочников и на старте, дальше к нему добавляется свой метод в расширении под конкретную задачу. Как считать объемы выборок, где ставить срезы и что делать с нагрузкой на рабочую базу — это отдельная инженерная тема, она разобрана в статье про интеграцию ИИ с 1С и ERP. Здесь мы говорим про организацию работ, там — про архитектуру данных и нагрузку.
Почему тонкий коннектор переживает обновление
Инженерная формулировка простая: считайте поверхность соприкосновения. Это число типовых объектов, которых касается ваше решение. Чем оно меньше, тем меньше шансов, что очередной релиз что-то сломает.
Разделение выглядит так. В сервисе живет все, что меняется часто: модель, промпты, правила извлечения, сопоставление номенклатуры, пороги уверенности, очередь спорных, логи, дообучение. В базе живет то, что меняется редко: чтение нужных данных, запись объекта, отметка о результате. Первое обновляется без согласований и без окна обслуживания. Второе трогают раз в квартал.
Инвариант, который стоит записать в техническое задание: отключение расширения возвращает базу в исходное рабочее состояние. Проверяется за десять минут — выключаете расширение на тестовой копии и пробуете провести обычный день бухгалтерии.
Прямая доработка типовой нарушает этот инвариант по построению. Логика модели оказывается вшита в модуль документа, откатить ее нельзя без конфигуратора, а обновление вендора и ваши правки живут в одном файле и рано или поздно встречаются в конфликте.
Что именно отваливается на обновлении
Расширение расширению рознь. Ниже механизмы по убыванию риска — с этой таблицей стоит идти к подрядчику и спрашивать, что из перечисленного он собирается использовать.
| Что делает расширение | Риск на обновлении | Чем заменить |
|---|---|---|
| Аннотация &Вместо на типовой процедуре | Высокий: меняется сигнатура или процедура исчезает целиком | &После, подписка на событие, вынос логики в свой модуль |
| Заимствование типового документа ради нового реквизита | Средний: состав реквизитов меняется от релиза к релизу | Свой регистр сведений в расширении с привязкой по ссылке |
| Изменение типовой формы | Средний: форму переверстывает вендор | Отдельная форма обработки, вызов через дополнительные обработки |
| Свой HTTP-сервис и свои общие модули | Низкий: собственные объекты вендор не трогает | Это и есть тонкий коннектор |
| Свой регистр сведений под статусы и очередь | Низкий | Оставить как есть |
Вторая строка тут самая полезная. Желание добавить в типовой документ пару реквизитов возникает почти в каждом проекте, и почти всегда оно решается отдельным регистром сведений, где ключ — ссылка на документ, а ресурсы — результат работы модели, уверенность и время обработки. Типовой объект при этом остается нетронутым, а данные никуда не пропадают при обновлении.
Отдельный класс проблем дают базы, которые правились годами до вас: неполный состав опубликованного интерфейса, переписанное проведение, урезанные права служебных учетных записей. Что именно ломается в такой конфигурации, разобрано в статье что ломается в конфигурации с 2011 года. Обследование до сметы существует ровно для того, чтобы это всплыло до денег.
Регламент обновлений: три правила в договор
Проект не заканчивается приемкой, он заканчивается первым релизом типовой после внедрения. Три пункта, которые дешево записать заранее.
- Тестовая копия обязательна. Обновление сначала на копии, с прогоном обмена, потом в бой. Если копии нет, заводить ее надо в любом случае, безотносительно ИИ.
- Падение обмена должно быть громким. Расширение отключилось, метод вернул ошибку, очередь не разбирается два часа — все это уходит письмом или сообщением ответственному. Тихая остановка обмена обнаруживается на закрытии месяца, и это худший способ ее обнаружить.
- Совместимость с новым релизом — работа, у которой есть срок и цена. Формулировка в договоре: подрядчик приводит коннектор в рабочее состояние за оговоренное число рабочих дней после того, как клиент сообщил дату обновления. Заранее, не задним числом.
Кто что делает: подрядчик по ИИ и ваш 1С-ник
Техника на таких проектах обычно доводится. Встают они на стыке: две команды, и каждая уверена, что публикацию веб-сервера делает соседняя. Таблица ниже переносится в договор почти дословно.
| Зона | Подрядчик по ИИ | 1С-ник заказчика |
|---|---|---|
| Модель и обработка данных | Полностью: извлечение, сопоставление, пороги, дообучение | Не участвует |
| Контракт обмена | Описывает форматы, версии, коды ошибок | Согласовывает состав полей и объем выборок |
| Коннектор в базе | Пишет, если получает доступ к конфигуратору | Пишет, если конфигурация под его ответственностью |
| Публикация и доступы | Формулирует требования | Веб-сервер, сертификат, служебная учетная запись, профиль прав |
| Тестовый контур | Проверяет релизы на копии | Разворачивает и обновляет копию |
| Обновление типовой | Чинит коннектор в оговоренный срок | Сообщает дату заранее, прогоняет обновление на копии |
| Приемка | Готовит замер на согласованной выборке | Проверяет документы в базе вместе с бухгалтерией |
Главный спорный пункт — третья строка. Вариантов ровно три, и выбрать надо до договора. Коннектор пишет подрядчик по ИИ: быстрее, но нужен доступ в конфигуратор и согласие тех, кто отвечает за базу. Коннектор пишет ваш франчайзи или штатный разработчик: медленнее на пару недель, зато конфигурация остается в одних руках и никто не спорит о причинах сбоя. Третий вариант — коннектора нет вовсе, работаем на выгрузках; он годится для пилота и не годится для промышленной эксплуатации.
Что бы вы ни выбрали, контракт обмена описывает подрядчик по ИИ, и описывает его до начала работ. Документ на две страницы: какие методы, какие поля, что считается ошибкой, как версионируется. Без него стык превращается в переписку.
Восемь вопросов подрядчику до договора
Полчаса разговора. Каждый ответ либо снимает риск, либо показывает, где будет больно. Спрашивать стоит именно в такой формулировке: общие вопросы получают общие ответы.
- Какой способ обмена вы предлагаете именно на нашей конфигурации и почему не два других?
- Конфигурация останется на поддержке? Если делаете расширение — перечислите заимствованные типовые объекты.
- Сколько типовых процедур подменяется аннотацией &Вместо? Ноль — хороший ответ, «пара штук» — повод разобрать каждую.
- Что происходит при обновлении типовой: кто проверяет применимость, за чей счет и в какой срок?
- Можно ли начать без доступа в базу, на выгрузках, и что мы увидим через три недели?
- Как выглядит откат: сколько минут занимает отключение и что останется в базе после него?
- Какие объекты пишет сервис и в каком состоянии — черновик или проведенный документ?
- Кому принадлежат права на коннектор и модель после оплаты этапа?
Про седьмой пункт стоит сказать прямо. Здоровая схема на старте: сервис создает документ черновиком, проведение остается за человеком до тех пор, пока вы сами не решите иначе по конкретному типу документа. Требование проводить автоматически с первого дня удваивает цену ошибки и обычно появляется от людей, которые не разбирают ее последствия.
Чек-лист готовности учетной системы
День работы вашего 1С-ника. Ответы на эти десять пунктов — почти готовое техническое задание на интеграцию, и по ним подрядчик дает вилку без риск-надбавки за неизвестность.
- Версия платформы, редакция и релиз конфигурации, дата последнего обновления.
- Состояние поддержки: сколько объектов снято и сколько редактируется с сохранением поддержки. Цифра берется из настройки поддержки; по памяти ее не знает никто.
- Список установленных расширений и их назначение. Есть ли среди них отключенные и почему.
- Опубликован ли веб-сервер, есть ли действующий сертификат, кто им владеет.
- Что опубликовано через OData: поименный перечень объектов. Ответ «вроде бы все» тут не годится.
- Есть ли тестовая копия базы, как часто обновляется, кто ее разворачивает.
- Регламент обновлений: частота, окно, ответственный, среднее время на объединение за прошлый год.
- Файловый вариант или клиент-серверный, размер базы, окно ночных регламентных заданий.
- Кто отвечает за конфигурацию: штатный разработчик, франчайзи, никто.
- Требования к контуру: допустимо ли отправлять данные во внешнее облако или все считается на своих серверах.
Последний пункт лучше выяснить до выбора способа обмена. Он определяет не только архитектуру, но и бюджет: локальный контур требует железа под инференс, и эта строка появляется в смете сразу.
Когда без правки типовой действительно не обойтись
Честная оговорка, чтобы статья не выглядела рекламой расширений. Есть задачи, где коннектор снаружи не помогает.
- Изменение поведения типового проведения. Если модель должна влиять на движения документа в момент проведения, точка вмешательства одна, и она внутри типовой логики. Даже здесь расширение с аннотацией предпочтительнее правки: оно отключается одним флажком.
- Самописная конфигурация. Понятия поддержки там нет, эталона вендора тоже, правки — обычная жизнь этой базы. Разговор про расширения теряет смысл, зато появляется разговор про регламент разработки и тестовый контур.
- Глубоко переписанная типовая. Если база уже снята с поддержки много лет назад, беречь нечего. Обсуждать надо другое: как вы вообще обновляетесь и что будет с решением, когда вы наконец соберетесь мигрировать на свежий релиз.
Когда затею стоит отложить
Пять ситуаций, в которых правильный ответ — сначала навести порядок, потом звать подрядчика по ИИ.
- За базу никто не отвечает. Штатного 1С-ника нет, франчайзи меняется каждый год, паролей от конфигуратора не найти. Любой интеграционный проект тут упрется в первую неделю.
- Нельзя сделать тестовую копию. Значит, обновления и обмен вы проверяете сразу на боевой базе. Такая проверка называется лотереей и разыгрывается обычно в день закрытия месяца.
- Конфигурация не обновлялась несколько лет. Обновление само по себе станет проектом на месяцы, и делать его надо до, не после.
- Задача закрывается штатным механизмом. Прежде чем заказывать модель, спросите своего 1С-ника, нет ли этого в типовой. Иногда нужен не ИИ, а включенная галочка и полчаса настройки.
- Объем работы не набирает порога. Три накладные в день и десять писем в неделю не окупают ни один проект. Считать надо часы, которые уходят сейчас, и делать это секундомером.
Что дальше
Порядок работ, сроки и вилки по сценариям внутри учетной системы — на странице ИИ в 1С: первый процесс от 250 000 ₽, 3–5 недель до пилота. Прикинуть бюджет под свою задачу можно на калькуляторе, а схема оплаты стандартная: работы до 300 000 ₽ разово, выше — половина на старте, 30% после демонстрации на ваших данных, остаток после передачи.
Разговор идет быстрее всего, если у вас на руках заполненный чек-лист выше. По четырем пунктам из десяти — состояние поддержки, список расширений, состав опубликованного интерфейса и наличие тестовой копии — уже видно, какой способ обмена вам подходит и сколько будет стоить коннектор. До договора и без обязательств с вашей стороны.