Сценарий, с которого обычно начинается разговор. Бухгалтерия ставит внешнюю обработку СБИС в свою 1С, запускает — и получает «Конфигурация 1С не поддерживается». Либо обработка встает, но не видит половину документов: реализация уходит пустой, входящее поступление не создается, сопоставление номенклатуры слетает после обновления. Пятилетняя база с десятком доработок, и штатная схема на ней работать не рассчитана.
Это не поломка и не чей-то недосмотр. Тензор описывает границу прямо в своей документации: штатные средства интеграции поддерживают только стандартные конфигурации 1С. Все, что за этой границей, — работа подрядчика. Мы этим и занимаемся.
Цена и сроки
Адаптация обмена под доработанную конфигурацию — от 90 000 ₽ и 2–3 недели. Свои типы документов, несколько баз или юрлиц — от 220 000 ₽. Обмен на API в обход обработки — от 450 000 ₽. До 300 000 ₽ оплата разовая.
Сразу о том, когда мы не нужны
Если у вас типовая конфигурация свежего релиза из списка поддерживаемых, один ящик и обычные накладные, то задача решается настройкой. Стоит она тысячи рублей, а не сотни тысяч, и делает ее любой франчайзи или ваш приходящий специалист. Идти за этим к нам смысла нет, и мы скажем это на первом же разговоре.
Второй случай, когда мы лишние: база отличается от типовой мелочами, и вам нужна только выгрузка отгрузок. На рынке продаются готовые сторонние обработки под такую задачу, стоят они десятки тысяч рублей и покрывают распространенные сценарии на популярных конфигурациях. Если ваш случай в них попадает, это самый дешевый выход, и мы первыми посоветуем начать с него.
Разработка от 90 000 ₽ имеет смысл там, где готовое не встает: свои типы документов, реквизиты, которых нет в чужих правилах обмена, несколько баз и юрлиц, требование пережить обновление без ручной работы. Дальше — про этот случай.
Почему штатная обработка не встает на доработанной базе
Причина техническая и вполне объяснимая. Правила обмена внутри обработки — это файлы настроек, а не универсальный код. В имени такого файла зашиты код конфигурации и минимальная редакция, под которую он написан, а внутри — имена объектов метаданных вашей 1С: конкретный документ, конкретные реквизиты, конкретные табличные части.
Отсюда три типовых обрыва:
Свой или переименованный документ. В базе живет «РеализацияТоваровУслугСпец» вместо типовой реализации, потому что пять лет назад так было проще. Правил под этот документ не существует, и появиться им неоткуда.
Свои реквизиты. В шапку добавили признак сделки, в табличную часть — свой артикул или номер партии. В выгрузку они не попадают, потому что настройка про них не знает.
Ушедшая редакция. База осталась на старой ветке конфигурации или обновляется по своему графику. Правила рассчитаны на другую редакцию и ведут себя непредсказуемо: часть полей заполняется, часть молча теряется.
Отдельная категория — отраслевые сборки. Тензор оговаривает, что релизы официальных конфигураций, доработанные под отрасль или конкретное предприятие, поддерживаются не полностью. Владелец такой базы обычно уверен, что у него типовая: коробка куплена у вендора, а хвост в номере версии никто не разглядывал.
Штатный слой пользовательских настроек и его потолок
В обработке предусмотрен способ дописать логику, не трогая код: рядом подключается слой пользовательских функций. Механизм рабочий, и часть задач он закрывает.
Потолок у него в одном: переопределить можно только то, что уже есть в базовой настройке. Если реквизита в ней нет, слой его не подхватит и по этому элементу не выполнится вовсе. То есть ровно тот случай, ради которого его обычно и открывают — добавить свое поле в обмен, — им и не решается.
Дальше начинается развилка. Либо править базовые файлы настроек, которые затрутся при ближайшем обновлении. Либо строить обмен так, чтобы он пережил обновление. Мы делаем второе, и об этом следующий раздел.
Обновления — место, где обмен обычно и умирает
Компания один раз настроила обмен руками, все заработало, о задаче забыли. Через полгода ФНС меняет формат документа, обработка обновляется, ручные правки исчезают вместе со старой версией. Обмен встает в самый неудобный момент — на отгрузках, когда покупатель ждет документы.
Штатный совет на этот случай звучит как «перенесите правки вручную после обновления», и для доработанной базы это означает: каждое обновление превращается в маленький проект с участием программиста. Поэтому свою часть работы мы изначально держим отдельно от обновляемых файлов — в расширении конфигурации со своей логикой. Обновление обработки перестает быть событием.
Три схемы, по которым мы это делаем
Адаптация штатной схемы. Обработка остается, к ней достраиваются правила и логика под ваши документы и реквизиты, наша часть живет в расширении. Самый дешевый путь, подходит, когда база доработана, но узнаваема.
Расширение с собственной логикой обмена. Когда документы свои, юрлиц несколько или маршрут документа завязан на ваши согласования. Обработка используется как транспорт, а решения о том, что и когда уходит, принимает наш код.
Свой обмен на API. СБИС дает программный интерфейс по протоколу JSON-RPC: аутентификация, список документов, запись документа, переходы по этапам. Когда конфигурация самописная или обработка на ней принципиально не живет, обмен строится прямо на API, без внешней обработки вообще. Здесь же учитываются лимиты сервиса на размер вложений и число параллельных потоков — на потоке в сотни документов это перестает быть теорией.
Что мы не продаем
Мы не оператор электронного документооборота, не удостоверяющий центр и не сервис-центр СБИС. Тарифы, лицензии и электронные подписи оформляются вами напрямую у Тензора: через подрядчика это всегда дороже и медленнее. Наша работа начинается там, где все это уже есть, а обмен с вашей 1С не складывается.
Роуминг и приглашения
С Контуром у СБИС связь работает без отдельной настройки. С остальными операторами настройка занимает время, и на этом этапе проекты обычно вязнут: часть контрагентов подключилась, часть висит в приглашениях неделями.
Отдельная засада ждет тех, кто раньше работал в СБИС, а потом завел идентификатор в 1С-ЭДО. Приглашения с нового идентификатора абонентам СБИС могут автоматически отклоняться, пока прежний документооборот не отключен на стороне оператора, и делается это не за один день. Разбирать такое лучше до того, как отдел продаж начнет рассылать приглашения всей базе контрагентов.
Что вы получаете на выходе
Работающий обмен на ваших реальных документах, схему решения, исходники расширения и инструкцию для бухгалтерии. Плюс понимание, что произойдет при следующем обновлении — потому что оно произойдет.
Соседние задачи
Если операторов несколько или вопрос шире одного вендора — общая страница про интеграцию 1С с ЭДО: роуминг, сопоставление номенклатуры, массовое подписание. Часть поставщиков останется на бумаге и сканах, и для них работает распознавание первичных документов. Когда входящие начнут попадать в базу сами, следующим вопросом станет, сходятся ли они с заказами, — это автоматическая сверка. Остальные направления и общий порядок работы собраны в разделе интеграции 1С.