Услуга
Настройка интеграции 1С с другими системами
Настроим интеграцию 1С с другой информационной системой: определим, какие данные и в каком направлении должны передаваться, выберем поддерживаемый механизм подключения, согласуем правила идентификации объектов и предусмотрим контроль ошибок и повторной передачи.
4 500 ₽/час
До начала разработки проверим обе системы, доступные интерфейсы, объекты обмена, объём и периодичность данных, требования к безопасности и критерии приёмки.
Оценить интеграцию
Когда нужна интеграция 1С с другой системой
Интеграция нужна, когда данные должны регулярно передаваться между 1С и другой информационной системой без повторного ручного ввода.
Например, задача может включать обмен с:
- CRM;
- интернет-магазином или сайтом;
- WMS;
- MES;
- корпоративным порталом;
- системой электронного документооборота;
- внешним сервисом;
- мобильным приложением;
- оборудованием;
- другой учётной или производственной системой.
Задача интеграции — не просто передать набор полей. Необходимо обеспечить предсказуемое движение данных: определить источник каждого объекта, правила сопоставления, порядок повторной передачи, контроль ошибок и способ проверки результата.
Сначала проверяем штатные возможности
Платформа 1С:Предприятие поддерживает несколько механизмов взаимодействия с внешними системами. В зависимости от задачи могут использоваться HTTP- и web-сервисы, стандартный интерфейс OData, работа с внешними HTTP-сервисами и другие поддерживаемые механизмы.
Но наличие технической возможности ещё не означает, что нужно сразу разрабатывать собственный API.
Перед разработкой проверяем:
- есть ли готовая интеграция в используемой конфигурации;
- существует ли штатный модуль обмена;
- поддерживает ли внешняя система стандартный интерфейс;
- можно ли решить задачу типовой синхронизацией;
- можно ли использовать существующий API без изменения основной конфигурации;
- требуется ли собственный механизм только для недостающей части процесса.
Использование готового поддерживаемого механизма обычно упрощает дальнейшее обновление и сопровождение системы.
Интеграция и типовая синхронизация — разные задачи
Типовая синхронизация
Используется, когда для конкретной пары решений 1С уже предусмотрен штатный обмен и стандартного состава передаваемых данных достаточно.
В таком случае предпочтительно сначала использовать типовую синхронизацию между базами 1С.
Индивидуальная интеграция
Нужна, когда связываются разные информационные системы либо стандартного обмена недостаточно для требуемого процесса.
Тогда отдельно проектируются интерфейс, структура данных, правила идентификации, обработка ошибок и контроль повторов.
Не следует разрабатывать собственный обмен между двумя типовыми базами 1С, если существующий штатный механизм уже решает задачу без изменения стандартных правил.
Сначала определяем источник данных
До разработки интеграции необходимо решить, какая система отвечает за создание и изменение каждого вида данных.
Например:
- клиенты могут создаваться в CRM, а затем передаваться в 1С;
- номенклатура может вестись только в 1С;
- остатки рассчитываются в 1С и передаются на сайт;
- заказы покупателей поступают из интернет-магазина в 1С;
- статус оплаты или отгрузки возвращается из 1С во внешнюю систему.
Не обязательно назначать одну систему главным источником абсолютно всех данных. Источник определяется отдельно для каждого объекта или группы реквизитов.
Односторонний и двусторонний обмен
Односторонний обмен
Данные движутся только в одном направлении.
Например:
- остатки и цены из 1С на сайт;
- заказы из интернет-магазина в 1С;
- справочник товаров из 1С во внешнюю систему.
Такой сценарий обычно проще контролировать, поскольку для передаваемого объекта заранее понятен основной источник.
Двусторонний обмен
Обе системы могут передавать данные друг другу.
В этом случае дополнительно необходимо определить:
- какие объекты создаются на каждой стороне;
- какие реквизиты можно изменять;
- как обрабатываются одновременные изменения;
- какая система имеет приоритет при конфликте.
Двусторонний обмен не должен означать, что любые изменения бесконтрольно копируются в обе стороны.
Для каждого объекта нужен устойчивый идентификатор
Чтобы система могла понять, что полученный объект уже существует, необходимо определить правило идентификации.
В зависимости от данных это может быть:
- GUID или другой уникальный идентификатор;
- внешний код;
- артикул;
- штрихкод;
- номер заказа внешней системы;
- ИНН и КПП для подходящего сценария;
- заранее сформированная таблица соответствий;
- другой устойчивый ключ.
Наименование обычно не является хорошим универсальным идентификатором: оно может измениться, отличаться по написанию или совпасть у разных объектов.
Таблица соответствий между системами
Объекты двух систем не обязаны иметь одинаковые внутренние идентификаторы.
Например, одна и та же номенклатура может иметь:
- ссылку 1С;
- внешний ID сайта;
- код CRM;
- артикул поставщика.
В таких случаях используется устойчивое правило сопоставления или отдельное хранение соответствий.
Это позволяет при последующих обменах обновлять существующий объект, а не создавать новый экземпляр каждый раз.
Что делать, если соответствие не найдено
Для каждого типа объекта заранее определяется поведение системы.
Подходит, если внешняя система действительно имеет право создавать этот тип данных в 1С.
Используется, если отсутствие соответствия означает ошибку исходных данных или нарушение процесса.
Подходит для неоднозначных объектов, когда автоматическое создание может привести к дублям.
Используется, если сначала должен быть загружен связанный объект, например контрагент до его договора или номенклатура до строки заказа.
Не следует использовать универсальное правило «если не найдено — создать» для всех справочников и документов.
Порядок передачи связанных данных
Объекты информационной системы связаны друг с другом.
Например, заказ может ссылаться на:
- контрагента;
- договор;
- организацию;
- склад;
- номенклатуру;
- характеристики;
- единицы измерения.
Если документ поступил раньше необходимых справочников, его корректная загрузка может быть невозможна.
Поэтому при проектировании интеграции определяется порядок передачи связанных объектов и поведение при отсутствии обязательной зависимости.
Контракт данных должен быть определён заранее
До программирования фиксируем, какие данные стороны передают друг другу.
Для каждого сообщения или объекта полезно определить:
- назначение сообщения;
- обязательные поля;
- необязательные поля;
- типы значений;
- формат дат и чисел;
- идентификаторы объектов;
- правила обработки пустых значений;
- версию формата;
- ожидаемый ответ принимающей системы.
Такой договорённый формат позволяет изменять системы осознанно и отличать ошибку передачи от ошибки самих исходных данных.
Выбор технического механизма
После определения бизнес-процесса и структуры данных выбирается подходящий способ взаимодействия.
В зависимости от систем и требований это может быть:
- HTTP-сервис 1С;
- обращение из 1С к внешнему HTTP API;
- web-сервис;
- стандартный OData-интерфейс;
- файловый обмен;
- другой поддерживаемый механизм платформы или внешней системы.
Выбор зависит от:
- возможностей обеих систем;
- направления обмена;
- объёма и частоты сообщений;
- требований к безопасности;
- необходимости оперативного ответа;
- инфраструктуры заказчика;
- требований к дальнейшему сопровождению.
Не следует создавать собственный HTTP-сервис только потому, что такой механизм доступен технически. Если задача надёжно решается стандартным интерфейсом, дополнительный собственный код может быть избыточен.
Синхронный и асинхронный обмен
Не каждый интеграционный процесс должен ждать мгновенного ответа второй системы.
Синхронный сценарий
Система отправляет запрос и ожидает результат в рамках текущей операции.
Такой вариант подходит, например, когда пользователю сразу требуется:
- получить актуальную цену;
- проверить наличие товара;
- получить идентификатор созданного объекта;
- проверить результат короткой операции.
При этом необходимо учитывать доступность внешней системы и допустимое время ожидания.
Асинхронный сценарий
Отправка и фактическая обработка данных разделены по времени.
Такой вариант полезен, когда:
- обрабатывается большой объём данных;
- внешняя система может временно быть недоступна;
- операцию можно повторить позже;
- не нужно блокировать пользователя до завершения внешней обработки.
Способ взаимодействия выбирается по требованиям бизнес-процесса, а не только по удобству программирования.
Таймауты и недоступность внешней системы
Любая внешняя система может временно отвечать медленно или быть недоступна.
Поэтому для сетевой интеграции заранее определяем:
- сколько времени допустимо ожидать ответа;
- что считается технической ошибкой;
- можно ли повторить операцию;
- сколько повторов допустимо;
- когда требуется вмешательство пользователя;
- что происходит с бизнес-операцией в 1С при отсутствии ответа.
Не следует оставлять пользовательскую операцию в неопределённом ожидании внешнего сервиса без ограничения времени и понятного результата.
Повторная отправка не должна создавать дубли
Одна из ключевых задач интеграции — безопасно обработать повтор.
Повторная отправка может возникнуть, если:
- ответ внешней системы не дошёл до 1С;
- соединение оборвалось после фактической обработки запроса;
- пользователь повторно запустил операцию;
- регламентное задание выполняет повтор после технической ошибки;
- один и тот же файл или сообщение поступило повторно.
Если принимающая система уже создала заказ, платёж или другой объект, повтор не должен бесконтрольно создавать ещё один такой же объект.
Для этого заранее определяются:
- уникальный идентификатор сообщения;
- внешний идентификатор объекта;
- правило проверки ранее обработанных данных;
- ожидаемое поведение при повторной передаче.
Статус сообщения должен быть понятен
Для важных обменов недостаточно знать только факт запуска интеграции.
Полезно различать состояния, например:
- подготовлено к отправке;
- отправляется;
- передано внешней системе;
- успешно обработано;
- ожидает повторной обработки;
- завершено с ошибкой.
Точный набор состояний определяется конкретной интеграцией.
Главное, чтобы можно было ответить на вопрос:
что произошло с конкретным объектом и нужно ли выполнять какое-либо действие сейчас.
Ошибки транспорта и ошибки данных — разные проблемы
Техническая ошибка
Например:
- внешний сервис недоступен;
- истёк таймаут;
- ошибка авторизации;
- не удалось установить защищённое соединение;
- получен неожиданный технический ответ.
Такую операцию иногда можно повторить после устранения технической причины.
Ошибка содержимого
Например:
- не найден контрагент;
- отсутствует обязательный реквизит;
- неизвестна номенклатура;
- передано недопустимое значение;
- нарушено бизнес-правило принимающей системы.
Простой повтор того же сообщения обычно не устранит такую проблему.
Разделение типов ошибок позволяет не выполнять бессмысленные автоматические повторы сообщений с некорректными данными.
Журналирование должно помогать найти конкретную проблему
Для сопровождаемой интеграции необходимо иметь возможность восстановить ход обмена без изучения всей информационной базы вручную.
В зависимости от критичности процесса полезно фиксировать:
- дату и время операции;
- направление обмена;
- тип объекта;
- внешний или внутренний идентификатор;
- результат обработки;
- код или описание ошибки;
- номер попытки;
- связь с исходным сообщением.
При этом журнал не должен бесконтрольно сохранять пароли, токены, закрытые ключи и другие секретные данные.
Аутентификация и секреты
Если системы взаимодействуют через сетевой интерфейс, заранее определяется механизм аутентификации.
Это может быть предусмотренная внешней системой схема:
- отдельная техническая учётная запись;
- API-ключ;
- токен доступа;
- сертификат;
- другой поддерживаемый способ.
Не следует:
- встраивать пароль непосредственно в публикуемый программный код;
- передавать секреты через открытую форму сайта;
- записывать токены в обычный журнал ошибок;
- использовать личную административную учётную запись сотрудника как постоянную техническую интеграционную учётную запись без необходимости.
Способ безопасного хранения и обновления секретов определяется с учётом возможностей обеих систем и инфраструктуры заказчика.
Доступ интеграции должен быть ограничен её задачей
Интеграционной учётной записи не требуется автоматически предоставлять максимальные права в информационной системе.
Если внешний сервис должен только:
- получать остатки;
- создавать заказы;
- читать справочник товаров;
доступ желательно ограничивать теми функциями и данными, которые действительно необходимы для этого процесса.
Если для работы интеграции требуется настройка штатных пользователей и ролей, дополнительно может использоваться услуга настройки пользователей и типовых прав доступа 1С.
Полная выгрузка и передача только изменений
Не для каждой интеграции правильно при каждом запуске передавать весь справочник или все документы заново.
Возможны два основных сценария:
Полная выгрузка
Подходит, когда:
- объём данных небольшой;
- получателю нужен полный актуальный снимок;
- обмен выполняется редко;
- стоимость повторной передачи невелика.
Передача изменений
Подходит, когда:
- объём данных большой;
- обмен выполняется регулярно;
- нужно передавать только новые или изменённые объекты;
- полная выгрузка создаёт избыточную нагрузку.
Выбор механизма зависит от объёма информации, возможностей обеих систем и требований к актуальности данных.
Если используется передача изменений, необходимо понимать, как система определяет, что объект был изменён и успешно ли это изменение уже передавалось.
Регистрация изменений должна учитывать результат обмена
Недостаточно просто отметить объект как изменённый.
Для надёжного обмена важно различать состояния:
- изменение обнаружено;
- сообщение подготовлено;
- отправка выполнена;
- принимающая система подтвердила обработку;
- возникла ошибка;
- требуется повтор.
Если изменение считать успешно переданным до подтверждения результата, при техническом сбое часть данных может потеряться для второй системы.
Большие объёмы данных лучше передавать порциями
Передача десятков или сотен тысяч объектов одним запросом может привести к:
- долгому времени обработки;
- таймаутам;
- большому потреблению памяти;
- сложности повторной обработки после ошибки;
- повышенной нагрузке на обе системы.
Для больших массивов данных можно использовать пакетную обработку.
Например:
- передавать данные ограниченными порциями;
- фиксировать номер или идентификатор пакета;
- контролировать результат каждой порции;
- повторять только неуспешную часть;
- ограничивать длительность одной операции.
Размер пакета выбирается по результатам тестирования и зависит от структуры сообщения, производительности систем и сетевого канала.
Один большой пакет и множество маленьких запросов — оба варианта имеют ограничения
Слишком большой пакет
Может вызвать:
- таймаут;
- высокую нагрузку;
- сложный повтор после частичной ошибки;
- большой объём памяти.
Слишком много мелких запросов
Может увеличить:
- сетевые накладные расходы;
- число соединений;
- нагрузку на API;
- общее время обработки большого массива.
Поэтому размер пакета и частота запросов определяются для конкретного процесса, а не выбираются универсально.
Расписание или обмен по событию
Интеграция может запускаться по-разному.
По расписанию
Например:
- каждые несколько минут;
- раз в час;
- ночью;
- в определённые периоды рабочего дня.
Этот вариант удобен, если небольшая задержка допустима и данные можно обрабатывать накопленными пакетами.
По событию
Обмен запускается при определённом действии:
- создан заказ;
- изменился статус;
- поступила оплата;
- сформирован документ;
- внешняя система отправила уведомление.
Этот сценарий подходит, когда данные должны передаваться ближе к реальному времени.
Не следует делать интеграцию событийной только ради минимальной задержки, если бизнес-процесс спокойно допускает пакетную синхронизацию раз в несколько минут.
Webhook не гарантирует успешную обработку
Внешняя система может сообщать о событии через webhook или другой обратный вызов.
Получение такого уведомления означает только, что сообщение дошло до принимающего интерфейса.
Далее ещё необходимо:
- проверить подлинность или авторизацию вызова;
- проверить структуру данных;
- найти связанные объекты;
- выполнить бизнес-операцию;
- зафиксировать результат;
- корректно обработать повторное уведомление.
Если внутренняя обработка длительная, получение webhook лучше отделять от тяжёлой бизнес-операции, чтобы внешний сервис не ожидал завершения всего процесса в рамках одного сетевого запроса.
Частично обработанное сообщение требует отдельного сценария
Сложное сообщение может содержать несколько связанных элементов.
Например, заказ включает:
- контрагента;
- адрес доставки;
- десятки строк номенклатуры;
- скидки;
- способ оплаты;
- дополнительные реквизиты.
Если ошибка возникает в середине обработки, необходимо заранее определить:
- отменяется ли вся операция;
- можно ли сохранить корректную часть;
- какой статус получает сообщение;
- как будет выполняться повтор;
- не создаст ли повтор уже записанные объекты ещё раз.
Транзакция полезна, но не может охватить две независимые системы целиком
Внутри одной информационной базы изменения связанных данных можно выполнять согласованно, используя возможности платформы и прикладного решения.
Но невозможно считать обычную транзакцию 1С общей транзакцией одновременно для:
- 1С;
- внешнего сайта;
- CRM;
- банковского API;
- другой независимой информационной системы.
Внешняя система может уже зафиксировать своё изменение в момент, когда локальная операция ещё завершилась ошибкой.
Поэтому для распределённых процессов дополнительно проектируются:
- подтверждения;
- статусы;
- повторные операции;
- компенсирующие действия;
- контроль фактического состояния обеих сторон.
Версионирование интерфейса интеграции
Интеграция живёт дольше первого запуска, поэтому изменения структуры данных нужно предусматривать заранее.
Со временем может измениться:
- состав обязательных полей;
- названия реквизитов;
- структура вложенных объектов;
- правила заполнения;
- допустимые значения;
- формат ответа;
- механизм авторизации.
Если одна сторона обновится раньше другой, старый потребитель не должен неожиданно перестать понимать сообщения без понятной причины.
Для критичных интеграций полезно определить версию контракта данных и порядок перехода на новую структуру.
Обратная совместимость
Не каждое изменение формата требует мгновенного обновления обеих систем.
Если это возможно, новые версии интерфейса проектируются так, чтобы:
- необязательные новые поля не ломали старого потребителя;
- старый формат поддерживался в переходный период;
- изменения обязательных реквизитов выполнялись контролируемо;
- момент отключения старой версии был заранее понятен.
Если изменение несовместимо со старым форматом, требуется отдельный план перехода.
Тестовая среда для интеграции
Для сложного обмена желательно иметь возможность проверить изменения до подключения к рабочим данным.
В зависимости от инфраструктуры тестовый контур может включать:
- копию информационной базы 1С;
- тестовый API внешней системы;
- sandbox поставщика;
- отдельные технические учётные данные;
- тестовые идентификаторы;
- обезличенный набор данных.
Не каждая внешняя система предоставляет полноценную тестовую среду. Если её нет, безопасный сценарий проверки согласуется отдельно.
Тестовая копия 1С не должна бесконтрольно выполнять реальные интеграционные вызовы в production-систему.
Тестовая база не должна отправлять реальные данные
Копия рабочей информационной базы может содержать:
- реальные адреса API;
- токены;
- регламентные задания;
- очередь неотправленных сообщений;
- настройки webhook;
- адреса электронной почты;
- другие внешние подключения.
Перед её использованием необходимо проверить и при необходимости ограничить такие взаимодействия.
Иначе тестовая система способна:
- повторно отправить заказ;
- изменить состояние внешней CRM;
- отправить реальное уведомление;
- повторно выгрузить документы;
- создать дубли во внешней системе.
Тестовые данные должны покрывать не только успешный сценарий
Проверка одного идеального объекта недостаточна.
Для интеграции полезно протестировать:
- новый объект;
- уже существующий объект;
- изменение ранее переданного объекта;
- повтор того же сообщения;
- отсутствующее обязательное поле;
- неизвестное соответствие;
- техническую недоступность внешней системы;
- ошибочный ответ API;
- большой пакет данных, если он предусмотрен;
- сценарий восстановления после ошибки.
Так проверяется не только основной путь, но и поведение системы в реальной эксплуатации.
Критичные сценарии определяем вместе с заказчиком
Разработчик знает технический механизм, но бизнес-критичность операции определяет заказчик.
До приёмки полезно зафиксировать, какие процессы нельзя нарушить.
Например:
- поступление заказов с сайта;
- обновление остатков;
- передача цен;
- изменение статуса отгрузки;
- передача данных в производство;
- получение оплат;
- обмен с WMS.
Это позволяет направить основное тестирование на действительно значимые операции, а не пытаться одинаково глубоко проверять все возможные сообщения.
Контрольные показатели после запуска
После ввода интеграции в работу полезно определить несколько простых показателей её состояния.
Например:
- время последнего успешного обмена;
- количество сообщений в очереди;
- число необработанных ошибок;
- возраст самого старого ожидающего сообщения;
- количество успешных и ошибочных операций за период;
- среднее время обработки, если это важно для процесса.
Конкретный набор определяется критичностью интеграции.
Мониторинг и уведомления
Если интеграция критична для ежедневной работы, можно предусмотреть уведомление ответственного сотрудника о проблеме.
Уведомлять имеет смысл о событиях, которые действительно требуют внимания, например:
- обмен не выполнялся дольше допустимого времени;
- накопилась очередь сообщений;
- повторные попытки не устранили ошибку;
- истёк срок действия токена или сертификата;
- внешняя система возвращает устойчивую ошибку;
- не найдено критичное соответствие.
Не следует отправлять уведомление о каждой временной сетевой ошибке, если система сама успешно выполняет повтор через несколько секунд.
Поддержка интеграции после изменения внешней системы
Даже если код 1С не менялся, внешний сервис может изменить:
- API;
- правила авторизации;
- сертификаты;
- адреса endpoints;
- ограничения частоты запросов;
- структуру ответа;
- допустимые значения реквизитов.
Если ранее работавшая интеграция перестала выполняться, сначала определяется, что изменилось на каждой стороне.
Не следует автоматически переписывать весь механизм обмена, пока причина неисправности не установлена.
Поддержка после обновления 1С
Обновление платформы или конфигурации также может затронуть собственную интеграцию.
После существенного перехода рекомендуется проверить:
- работу используемых расширений;
- HTTP- и web-сервисы;
- регламентные задания;
- структуру собственных объектов;
- контрольный исходящий запрос;
- контрольный входящий сценарий;
- обработку повторной передачи.
Если обновление затрагивает доработанную конфигурацию, отдельно может потребоваться обновление доработанной конфигурации 1С.
Перед запуском интеграции в рабочем режиме
Успешный тест ещё не означает, что интеграцию можно сразу включать для всего рабочего потока.
Перед production-запуском проверяем:
- адреса рабочих сервисов;
- рабочие учётные данные интеграции;
- права технических пользователей;
- расписание или события запуска;
- очереди сообщений;
- настройки журналирования;
- уведомления об ошибках;
- объём первоначальной передачи данных;
- контрольные сценарии;
- порядок возврата при критической проблеме.
Особенно важно убедиться, что тестовые адреса, sandbox-токены и временные параметры не остались в рабочей конфигурации.
Первоначальное наполнение и регулярный обмен — разные этапы
При запуске новой интеграции часто необходимо сначала передать уже существующие данные, а затем перейти к обработке новых изменений.
Первоначальное наполнение
Может включать:
- существующую номенклатуру;
- контрагентов;
- остатки;
- цены;
- активные заказы;
- другие необходимые для старта данные.
Для этого этапа может использоваться пакетная обработка большого массива.
Регулярный обмен
После первоначального наполнения передаются новые и изменённые объекты согласно рабочему процессу.
Такой режим обычно требует:
- регистрации изменений;
- очереди;
- контроля повторов;
- обработки ошибок;
- мониторинга состояния.
Не следует использовать одинаковый алгоритм полной выгрузки всего массива при каждом регулярном обмене, если в этом нет технической необходимости.
Параллельная работа старого и нового механизма требует контроля
Если новая интеграция заменяет уже существующий обмен, необходимо определить момент переключения.
Опасный сценарий — когда одновременно продолжают работать:
- старый файловый обмен;
- новый API;
- старое регламентное задание;
- новая очередь;
- ручная загрузка пользователем.
В результате один и тот же заказ, платёж, документ или изменение может поступить во вторую систему дважды.
Поэтому перед запуском определяем:
- когда прекращается старый механизм;
- какие сообщения уже находятся в обработке;
- с какого момента данные принимает новая интеграция;
- как проверить отсутствие разрыва и дублей в точке перехода.
План возврата нужен до переключения
Если новая интеграция влияет на критичный рабочий процесс, заранее определяем действия на случай серьёзной проблемы после запуска.
План возврата может включать:
- остановку нового задания;
- отключение endpoint;
- возврат к прежнему механизму;
- сохранение очереди необработанных сообщений;
- повторную отправку после исправления;
- контроль данных, которые успели обработаться до остановки.
Как проходит работа
Определяем, какие системы участвуют, какие данные должны двигаться между ними и зачем этот обмен нужен пользователям.
Для каждого типа объектов фиксируем, где они создаются, где изменяются и какая система считается основной.
Проверяем штатные интеграции, API, HTTP- и web-сервисы, OData, файловые и другие поддерживаемые механизмы.
Определяем структуру сообщений, обязательные поля, идентификаторы, правила сопоставления и версии формата.
Задаём таймауты, повторные попытки, статусы сообщений, журналирование и поведение при неоднозначных данных.
Настраиваем или разрабатываем необходимый механизм на стороне 1С и взаимодействие с внешней системой.
Тестируем успешную передачу, повтор, ошибочные данные, недоступность внешней системы и другие критичные ситуации.
Если это требуется, передаём согласованный стартовый массив и сверяем результат.
Включаем расписание или событийную обработку, контролируем точку переключения и первые реальные операции.
Контролируем очередь, ошибки, повторные операции, ключевые бизнес-сценарии и понятность мониторинга для ответственных сотрудников.
Когда интеграция считается готовой
Работа считается выполненной по согласованному сценарию, когда:
- определены источники основных данных;
- согласован состав передаваемых объектов и реквизитов;
- работает выбранный технический канал;
- объекты однозначно сопоставляются между системами;
- новые данные создаются по согласованным правилам;
- повтор одного сообщения не создаёт нежелательных дублей;
- технические ошибки отделяются от ошибок данных;
- неуспешные операции можно обнаружить и повторно обработать;
- критичные сценарии проверены;
- первоначальное наполнение сверено, если оно входило в задачу;
- настроен рабочий режим запуска;
- ответственный пользователь понимает, где увидеть состояние интеграции и ошибки.
Что не входит автоматически
В стоимость обычной задачи интеграции автоматически не включаются:
- разработка или изменение внешней системы;
- оплата стороннего API или сервиса;
- получение коммерческих лицензий;
- создание инфраструктуры высокой доступности;
- настройка VPN и всей сетевой инфраструктуры;
- проектирование информационной безопасности всей организации;
- очистка всех исторических дублей;
- переработка всех бизнес-процессов заказчика;
- миграция всех накопленных данных между системами;
- исправление всех ранее существовавших ошибок 1С;
- круглосуточный мониторинг 24×7;
- сопровождение API стороннего поставщика без отдельного соглашения.
Если дополнительная работа необходима для запуска интеграции, её состав и оценка согласуются отдельно.
Стоимость интеграции
4 500 ₽ за час работы специалиста.
Цена означает стоимость часа, а не фиксированную стоимость интеграции любой сложности.
Трудоёмкость зависит от:
- количества систем;
- доступности и качества API;
- количества объектов обмена;
- направлений передачи;
- объёма данных;
- частоты обмена;
- сложности сопоставления;
- обработки повторов;
- требований к безопасности;
- необходимости очереди и мониторинга;
- наличия тестовой среды;
- объёма первоначальной миграции;
- количества контрольных сценариев.
Для большой интеграции обследование и проектирование могут быть выделены в отдельный первый этап, после которого уточняется объём реализации.
Что потребуется для первичной оценки
Для начала достаточно сообщить:
- какая конфигурация 1С используется;
- с какой системой нужно связать 1С;
- какие объекты должны передаваться;
- в каком направлении идут данные;
- как часто требуется обмен;
- какой примерный объём данных;
- есть ли документация внешнего API;
- существует ли тестовый контур;
- какие операции наиболее критичны для бизнеса;
- работает ли сейчас какой-либо старый обмен.
Если технический способ интеграции пока неизвестен, его не нужно выбирать заранее — подходящий механизм определяется после анализа обеих систем.
Частые вопросы об интеграции 1С с другими системами
Что такое интеграция 1С с другой системой?
Это организованный обмен данными между 1С и другой информационной системой. Интеграция определяет не только технический канал передачи, но и состав данных, направление обмена, правила идентификации объектов, обработку ошибок, повторов и контроль результата.
С какими системами можно интегрировать 1С?
Возможность зависит от интерфейсов обеих систем. Это могут быть CRM, интернет-магазины, сайты, WMS, MES, корпоративные порталы, мобильные приложения, внешние сервисы, оборудование и другие информационные системы, если существует поддерживаемый способ обмена данными.
Всегда ли для интеграции нужен API?
Нет. В зависимости от задачи могут использоваться HTTP- и web-сервисы, OData, файловый обмен, штатные механизмы конфигураций или другие поддерживаемые способы взаимодействия. Технический механизм выбирается после анализа бизнес-процесса и возможностей обеих систем.
Можно ли использовать готовую интеграцию вместо разработки?
Да. Перед собственной разработкой сначала проверяются штатные возможности используемой конфигурации 1С и внешней системы. Если готовый механизм полностью решает задачу, его использование обычно проще для дальнейшего сопровождения.
Чем интеграция отличается от типовой синхронизации между базами 1С?
Типовая синхронизация использует готовые правила, предусмотренные разработчиками конкретной пары конфигураций. Индивидуальная интеграция требуется, когда связываются другие системы либо стандартного состава данных и правил недостаточно.
Можно ли сделать двусторонний обмен?
Да, если это требуется бизнес-процессом и поддерживается обеими системами. При двустороннем обмене заранее определяется, где создаётся каждый объект, какие реквизиты разрешено менять на каждой стороне и какая система имеет приоритет при конфликтующих изменениях.
Что такое источник данных?
Это система, которая считается основной для конкретного объекта или реквизита. Например, карточка товара может создаваться в 1С, заказ — на сайте, а статус отгрузки снова формироваться в 1С. Одна система не обязана быть источником всех данных сразу.
Как системы понимают, что объект уже существует?
Для каждого типа данных определяется устойчивый идентификатор или правило сопоставления. Это может быть внешний ID, GUID, артикул, штрихкод, номер заказа, комбинация реквизитов или отдельная таблица соответствий. Поиск только по наименованию обычно недостаточно надёжен.
Что происходит, если соответствие объекта не найдено?
Поведение определяется заранее. В зависимости от процесса объект можно создать, отклонить сообщение, отложить обработку или передать ситуацию пользователю для ручного сопоставления. Универсальное правило «не найдено — создать» подходит не для всех данных.
Как избежать дублей при интеграции?
До запуска определяются устойчивые идентификаторы объектов и сообщений, правила поиска существующих данных и поведение при повторной передаче. Повтор одного сообщения должен иметь заранее определённый результат и не создавать новый объект бесконтрольно.
Почему одно сообщение может прийти повторно?
Например, принимающая система могла обработать запрос, но ответ не дошёл из-за сетевого сбоя. Отправитель считает операцию неуспешной и выполняет повтор. Поэтому защита от повторной обработки является обязательной частью критичных интеграций.
Что делать, если внешняя система временно недоступна?
Для такого сценария определяются таймаут, количество повторных попыток, статус сообщения и порядок дальнейшей обработки. Временная ошибка связи не должна автоматически означать потерю передаваемых данных.
Можно ли автоматически повторять ошибочные сообщения?
Технические ошибки иногда имеет смысл повторять автоматически. Ошибки самих данных, например отсутствие обязательного реквизита или неизвестный контрагент, простым повтором обычно не исправляются. Эти два типа ошибок желательно обрабатывать отдельно.
Как понять, прошёл ли конкретный объект через интеграцию?
Для важных процессов предусматривается журнал или другой механизм контроля, позволяющий определить объект, направление обмена, время операции, результат и ошибку. Конкретный способ зависит от архитектуры интеграции.
Нужно ли хранить все передаваемые данные в журнале?
Не обязательно. Журнал должен помогать диагностировать обмен, но не превращаться без необходимости в полную копию конфиденциальных данных. Особенно не следует записывать в обычный журнал пароли, API-ключи, токены и закрытые ключи.
Как хранить API-ключи и пароли интеграции?
Способ зависит от используемых систем и инфраструктуры. Секреты не следует встраивать непосредственно в публикуемый код, передавать через открытую форму сайта или выводить в обычный журнал ошибок. Для интеграции желательно использовать отдельные технические учётные данные с необходимым уровнем доступа.
Нужно ли давать интеграции Полные права в 1С?
Не обязательно и обычно нежелательно без необходимости. Технической учётной записи достаточно тех функций и данных, которые требуются конкретному обмену. Например, интеграция, создающая заказы, не должна автоматически получать административный доступ ко всей информационной базе.
Можно ли передавать данные сразу после каждого изменения?
Да, если бизнес-процесс действительно требует близкого к реальному времени обмена. Но для некоторых задач эффективнее накопить изменения и отправлять их по расписанию или пакетами. Режим выбирается исходя из требований к актуальности и нагрузки.
Что лучше: обмен по расписанию или по событию?
Универсально лучшего варианта нет. Расписание удобно для пакетной обработки и допустимой задержки. Событийный обмен полезен, когда система должна быстро реагировать на создание заказа, изменение статуса или другое конкретное событие.
Что такое webhook и можно ли использовать его с 1С?
Webhook — один из вариантов уведомления системы о событии. Получение webhook ещё не означает успешное выполнение всей бизнес-операции: данные необходимо проверить, сопоставить, обработать и корректно учесть возможный повтор уведомления.
Как передавать большой объём данных?
Большие массивы часто удобнее обрабатывать порциями. Это снижает риск таймаутов, уменьшает объём повторной работы после ошибки и позволяет контролировать результат каждого пакета. Размер порции определяется тестированием конкретного процесса.
Можно ли каждый раз выгружать все данные целиком?
Иногда да, например для небольшого справочника или редкого обмена. Для больших и часто изменяемых массивов обычно эффективнее передавать только новые и изменённые объекты. Выбор зависит от объёма и требований внешней системы.
Что делать, если часть сообщения обработалась, а часть завершилась ошибкой?
Такой сценарий проектируется заранее. Нужно определить, должна ли вся операция отменяться, можно ли сохранить корректную часть, какой статус получает сообщение и как будет выполняться повтор без повторного создания уже записанных объектов.
Можно ли использовать одну транзакцию сразу для 1С и внешней системы?
Обычная транзакция одной информационной базы не является общей транзакцией одновременно для нескольких независимых систем. Поэтому распределённый процесс требует подтверждений, статусов, повторов или компенсирующих действий на случай, если одна система уже сохранила изменения, а другая завершилась ошибкой.
Зачем нужна версия API или формата данных?
Интерфейс интеграции со временем меняется. Версия помогает сторонам понимать структуру сообщения и контролируемо переходить на новую модель данных, не ломая работающих потребителей неожиданным изменением обязательных полей.
Нужна ли тестовая среда?
Для сложных и критичных интеграций она очень полезна. Можно проверить обмен на копии базы, sandbox внешнего сервиса или обезличенных данных. При этом тестовая копия 1С должна быть изолирована от реальных production-интеграций.
Почему нельзя просто скопировать рабочую базу для теста?
Копия может сохранить реальные адреса API, токены, регламентные задания и очередь сообщений. Если запустить её без подготовки, она способна повторно отправить реальные документы или изменить данные внешней системы. Поэтому внешние взаимодействия тестовой копии сначала проверяются и ограничиваются.
Какие тесты нужны перед запуском?
Помимо успешного сценария полезно проверить существующий объект, новый объект, повтор сообщения, ошибочные данные, отсутствие соответствия, недоступность внешней системы, ошибку API и восстановление обмена после устранения причины.
Как проверить, что интеграция работает после запуска?
Для критичных процессов определяются контрольные показатели: время последнего успешного обмена, размер очереди, количество ошибок, возраст необработанных сообщений и другие показатели, которые позволяют быстро обнаружить остановку процесса.
Можно настроить уведомления об ошибках?
Да, если это требуется и поддерживается выбранной архитектурой. Лучше уведомлять о проблемах, действительно требующих вмешательства, например длительной остановке обмена или накоплении очереди, а не о каждой кратковременной сетевой ошибке, которая была успешно обработана автоматически.
Что происходит после изменения API внешней системы?
Сначала определяется, что именно изменилось: адрес, структура сообщений, авторизация, сертификат, ограничения или другой параметр. После этого корректируется затронутая часть интеграции. Не всегда требуется переписывать весь механизм обмена.
Нужно ли проверять интеграцию после обновления 1С?
После существенного обновления желательно выполнить контрольные сценарии, особенно если интеграция использует собственные объекты, расширения, HTTP- или web-сервисы и регламентные задания. Само обновление не означает автоматически, что интеграция сломается, но проверка снижает риск обнаружить проблему уже в рабочем процессе.
Можно сначала передать старые данные, а потом включить регулярный обмен?
Да. Это распространённый сценарий: сначала выполняется первоначальное наполнение внешней системы существующими справочниками, остатками, ценами или другими данными, затем интеграция переходит к передаче только новых изменений.
Можно одновременно оставить старый и новый обмен?
Только если это специально предусмотрено архитектурой. Иначе один объект может передаваться двумя механизмами и создавать дубли. При замене старой интеграции заранее определяется точка переключения и состояние уже находящихся в обработке сообщений.
Нужен ли план возврата?
Для критичной интеграции желательно заранее понимать, как остановить новый механизм, сохранить необработанные данные и временно вернуть прежний процесс, если после запуска обнаружится серьёзная проблема.
Чем интеграция отличается от загрузки Excel?
Excel подходит для разовой или контролируемой пользователем файловой загрузки. Интеграция предназначена для регулярного взаимодействия систем и обычно включает автоматическую передачу, идентификацию объектов, обработку ошибок, повторов и мониторинг.
Можно ли интегрировать две базы 1С через собственный API?
Технически это возможно, но сначала нужно проверить наличие типовой синхронизации. Если штатный механизм уже решает задачу, собственная интеграция может только увеличить стоимость разработки и дальнейшего сопровождения.
Сколько стоит интеграция 1С?
Стоимость работы специалиста — 4 500 ₽ за час. Итоговый объём зависит от внешней системы, доступного API, количества объектов, направления и частоты обмена, правил сопоставления, обработки ошибок, безопасности, тестирования и первоначальной миграции данных.
Можно заранее назвать фиксированную стоимость интеграции?
Для небольшой и хорошо описанной задачи предварительная оценка возможна после изучения интерфейсов. Для сложной интеграции сначала разумно провести обследование и проектирование, после которых становится понятен объём реализации и тестирования.
Что нужно прислать для оценки?
Достаточно указать конфигурацию 1С, внешнюю систему, перечень передаваемых объектов, направления движения данных, требуемую периодичность и наличие документации API. Секретные ключи и рабочие пароли для первичной оценки не нужны.
Можно настроить интеграцию удалённо?
Да. Большинство задач по анализу, разработке и проверке интеграции выполняются удалённо при согласованном безопасном доступе к необходимым системам и тестовым интерфейсам.
Оценить интеграцию 1С с другой системой
Укажите используемую конфигурацию 1С, внешнюю систему и кратко опишите, какие данные должны передаваться между ними и в каком направлении. Если технический механизм пока неизвестен, выбирать API или другой интерфейс заранее не требуется — подходящий вариант определим после анализа обеих систем.