Можно начать с одного обмена?
Да. Сначала определим законченный участок и его зависимости. Например, передача заявки без резервирования и оплаты может быть отдельным этапом, если это соответствует вашему процессу.
Настраиваем обмен между 1С, CRM, сайтом и другими сервисами: заказ передаётся в учёт, статус возвращается клиенту, а ошибка попадает ответственному. До разработки согласуем данные, правила операции и способ проверки результата. Разработка и доработка конфигураций 1С не входят в нашу услугу.
Начать можно с передачи заказа, обновления каталога, обмена документами или статуса для клиента. Согласуем, какие данные передаются и что подтверждает результат в каждой системе.
Максим Хорошко, руководитель команды ИТ-разработки АИС Сокол, лично разбирает задачу с владельцем процесса и специалистами подключаемых систем.
Мы реализуем согласованный внешний обмен. Изменения в сторонних программах и ответственность их сопровождающих команд определяем отдельно; конфигурации 1С не дорабатываем.
Для каждого объекта определяем источник, получателя и устойчивый идентификатор. Согласуем, какие поля можно менять на каждой стороне, когда отправлять обновление и как разбирать расхождения.
Каталог, обращения и учётные документы могут храниться в разных системах. Поэтому одна программа не обязательно становится главным источником всех данных. Важно определить правила для каждого объекта и не допустить независимого изменения одного поля без порядка разрешения конфликта.
Проверяем также связи между пользователями, организациями и документами. Доступ к обмену и данным ограничивается согласованными правами.
Сначала рассматриваем доступный модуль или штатный механизм обмена: поддерживаемые версии, нужные операции, ограничения и порядок обновления.
Если готовая основа не закрывает важные правила процесса, оцениваем доработку или собственный программный интерфейс. Проверяем, какие действия доступны через API и подходят ли они для вашего процесса.
Выбор зависит от конфигураций, размещения систем, прав доступа и ответственности за сопровождение. Необходимость замены действующей программы проверяем отдельно — это не исходное условие интеграции.
Возьмём отдельный API-сервис или модуль обмена в вашем проекте. До разработки определим его границы и результат, который примет ваша техническая команда.
Интерфейсы и данные. Согласуем входы и выходы: форматы запросов и ответов, обязательные поля, права доступа, ошибки и поведение при повторной операции. Закрепим контрольные примеры, по которым обе команды проверят модуль.
Код и ответственность. Определим, какую часть репозитория меняем, какие доступы и зависимости предоставляет партнёр и кто отвечает за подключаемые системы. Изменения за пределами модуля включаем только после согласования. Правила общения с конечным заказчиком определяем вместе с партнёром.
Проверка и приёмка. Заранее выберем тестовую среду, порядок проверки кода и ответственного за техническую приёмку со стороны партнёра. Сверим результат на обычной операции, повторе и выбранной ошибке, включая ответ связанной системы.
Передача. В согласованном объёме передадим код модуля, описание интерфейсов, контрольные примеры, результаты проверок и инструкцию подключения. Порядок включения в общий выпуск согласуем с основной командой.
В полностью разработанном нами TextFlow предусмотрены контроль ревизии черновика, ключ повторной операции и очередь публикаций. Эти механизмы помогают предметно обсудить работу API и обработку операций.
Первый разговор — бесплатно. Обсудим задачу и выясним, достаточно ли вводных для оценки. Для начала полезно подготовить:
В публичной форме достаточно краткого описания. Не отправляйте пароли, ключи, закрытые документы или рабочую базу. Порядок передачи проектных материалов согласуем отдельно.
Оцениваем конкретные данные и направления обмена. Стоимость зависит от качества исходных данных, нестандартных правил, доступности интерфейсов и тестовой среды. Дополнительные подключения согласуем отдельно.
До начала платных работ фиксируем результат этапа, зависимости, действия обеих сторон, критерии приёмки, срок и стоимость. Лицензии, инфраструктуру, платные внешние сервисы и сопровождение отражаем в предложении, когда они нужны.
Если без исследования действующей системы оценка невозможна, отдельно согласуем технический аудит — от 100 000 ₽. Он не обязателен для каждой интеграции. Бесплатный разговор не включает полный разбор кода, испытания и аудиторский отчёт.
Согласуем, как система распознаёт повторную операцию и что делает, если отправитель не получил ответ. Повтор одного заказа не должен считаться новым заказом; изменённые данные под прежним ключом требуют отдельного правила обработки.
Разделяем временные сбои связи и ошибки данных. Для них определяем порядок повторных попыток, уведомление ответственного и действия после исправления. Пользователь должен различать ожидание обработки, подтверждённый результат и ошибку.
В журнале предусматриваем сведения для поиска операции и причины сбоя, а не копию всех документов. Пароли, токены и лишние персональные данные в него не включаем. Объём записей, доступ и срок хранения согласуем отдельно.
До разработки определяем контрольные примеры и ожидаемый результат в каждой системе. Проверяем не только успешный запрос, но и смысл операции: состав, суммы, статусы и связь документов.
В согласованную проверку включаем обычную операцию, повтор, потерю ответа, недоступность одной стороны, некорректные данные и ограничения доступа. Проверки, способные повлиять на рабочую систему, проводим только в согласованных условиях.
Для запуска определяем момент переключения, ответственных и порядок остановки при проблеме. Возврат прежней версии программы не отменяет уже записанные документы в другой системе: такие изменения учитываем в плане восстановления.
Состав результата фиксируем до начала этапа. Он включает согласованные правила обмена, реализацию выбранного участка, материалы проверок и инструкции в предусмотренном договором объёме.
В инструкции описываем, где смотреть состояние обмена, как найти ошибку и какие действия может выполнить ответственный сотрудник. Указываем известные ограничения и зависимости. Исходники разработанных компонентов, настройки, сторонние лицензии и права на результат отражаем в составе передачи.
Сопровождение после запуска согласуем отдельно: режим работы, приоритеты обращений и ответственность. Изменения подключённых систем могут потребовать повторных проверок и доработки обмена.
Самостоятельная интеграция связывает уже работающие программы. Когда нужны новые роли, интерфейсы и правила работы с заявками или документами, обмен становится частью разработки информационной системы.
Для обмена между магазином, складом, оплатой и доставкой разбираем весь путь заказа. Запуск нового магазина — отдельная задача.
Подготовка обмена между 1С и сайтом подробно разобрана в практическом материале.
Да. Сначала определим законченный участок и его зависимости. Например, передача заявки без резервирования и оплаты может быть отдельным этапом, если это соответствует вашему процессу.
Нет. Сначала проверим возможности действующих систем. Совместимость конкретных версий, конфигураций и способов размещения требует проверки.
Он может закрыть выбранный сценарий. Но установка модуля не заменяет согласование данных и проверку операций, повторов, ошибок и прав. Необходимость доработки определим по результатам разбора.
Обсудим границы изменений и ответственность каждой команды, доступы, порядок проверки и передачи. Условия работы с кодом и материалами согласуем до начала.
Для оценки нужны состав данных, направления обмена, обычная операция и ограничения. Названия программ помогают проверить совместимость, а эти вводные — определить объём работ.
Напишите, какие системы нужно связать, что передавать и какой результат нужен первым. Уточним вводные и предложим подходящий следующий шаг.

Максим ХорошкоОснователь · работа с клиентами