Интеграция сайта с 1С: что согласовать между бухгалтерией, продажами и разработчиком

Почему настройку нужно начинать с общего разговора

Отдел продаж хочет видеть заказы с сайта в учётной системе сразу после оформления. Бухгалтерия ожидает проверенные реквизиты и правильные документы. Маркетолог рассчитывает, что на витрине всегда актуальны цены. Разработчик слышит общую задачу «связать сайт с 1С», но за ней скрываются несколько разных процессов.

Интеграция сайта с 1С становится управляемой, когда участники договорились, какие данные передаются, кто их проверяет и какое событие считается завершённым. Само соединение двух программ не определяет порядок продажи и учёта. Если правила не записаны, расхождения начинают обсуждать уже после появления реальных заказов.

Первый результат проекта — короткое согласованное описание обмена. Оно должно объяснять действия сотрудников и систем без программного кода. Подробности реализации специалисты добавят позже, но коммерческие условия, состав документов и ответственность за исходные сведения должны исходить от компании.

Составьте паспорт систем до оценки стоимости

На официальном сайте интеграции 1С и Битрикс представлены разные варианты взаимодействия продуктов. Наличие готового механизма не означает одинаковую совместимость всех конфигураций и доработок. Перед оценкой назовите точную конфигурацию 1С, её версию, платформу сайта, модули и существующий способ обмена.

Укажите, где находится база, кто её сопровождает, есть ли тестовая копия и какие обновления планируются. Для сайта понадобятся сведения о каталоге, заказах, личных кабинетах и уже работающих подключениях. Пароли в общий бриф не включайте: доступы передают выбранным специалистам отдельно, с необходимыми ограничениями.

Если 1С дорабатывали, попросите сопровождающего описать затронутые документы и справочники. Достаточно начать со списка отличий и контакта ответственного. Фраза «почти типовая» не позволяет понять, потребуется ли адаптация обмена после обновления.

Отдельно перечислите участников: разработчик сайта, специалист 1С, руководитель продаж и ответственный за учёт. У проекта должен быть один координатор, который фиксирует решения и контролирует сроки. Это не обязательно программист; его задача — не дать спорному вопросу затеряться между двумя исполнителями.

Опишите первый законченный процесс

Выберите процесс, который должен заработать в первой версии. Например: покупатель оформляет заказ, он появляется в 1С, менеджер проверяет состав, а согласованный статус возвращается на сайт. Это понятная граница для проверки. Требование автоматизировать все операции сразу труднее оценивать и принимать.

Запишите входные условия: кто покупатель, какой тип товара, доступна ли оплата, нужны ли особые цены, сколько организаций участвует. Затем перечислите результат на каждом шаге. Если процесс прерывается, должно быть понятно, кто узнает о проблеме и где увидит необработанное обращение.

Включите обычный и несколько исключительных сценариев. Для магазина это могут быть изменение состава, отмена, повторная отправка и отсутствие нужного контрагента. Перечень выбирают по реальным продажам. Нет смысла включать редкую операцию только потому, что она присутствует в демонстрации модуля.

Назначьте источник для каждого изменяемого значения

Цена, статус оплаты, адрес доставки и описание товара могут храниться в обеих системах. Нужно определить, где значение создают и какая сторона имеет право его менять. Иначе следующий обмен способен вернуть старое значение поверх ручной правки сотрудника.

Не обязательно назначать одну систему главной для всего. Например, учёт может отвечать за складские сведения, сайт — за редакторское описание, а сотрудник — за согласование нестандартного заказа. Главное, чтобы правило было определено для конкретного поля или события.

Проверьте ситуацию одновременного изменения: менеджер поправил заказ в 1С, пока покупатель редактировал его на сайте. Приоритет по времени, запрет изменения после определённого шага или ручное разрешение конфликта — возможные проектные решения. Нужный вариант выбирают заранее и проверяют на тесте.

Попросите бухгалтерию описать документы обычными словами

Название «заказ» на сайте не гарантирует, что в 1С будет создан документ с тем же деловым смыслом. Попросите ответственного за учёт указать, что должно появиться, в какой организации и с какими обязательными реквизитами. Разработчик затем сопоставит это с возможностями конфигурации.

Для каждого документа определите момент создания и условия изменения. Нужно ли сначала проверить клиента, можно ли передавать неполные реквизиты, кто исправляет ошибку? Если часть данных появляется после разговора с покупателем, процесс должен поддерживать этот этап, а не требовать выдуманное значение при первом обращении.

Отдельно согласуйте суммы, единицы измерения, скидки и округление. В документе могут быть дополнительные строки или услуги, которых нет в товарной карточке. Проверка только общего итога недостаточна: сумма иногда сходится даже при неправильном составе. Сверяйте позиции и условия расчёта на согласованных примерах.

Материал не заменяет правила бухгалтерского учёта вашей компании. Юридический и финансовый смысл документов подтверждает соответствующий специалист. Задача интегратора — реализовать и проверить согласованный порядок, а не самостоятельно решать, когда компания считает операцию состоявшейся.

Договоритесь о сопоставлении и защите от повторов

Система должна узнавать уже переданный товар, клиента или заказ. Для этого используют устойчивую связь записей. Имена и номера телефонов сами по себе не всегда позволяют безопасно определить совпадение: у организаций бывают одинаковые названия, у сотрудников — общие телефоны, у товара — изменённый артикул.

Попросите объяснить правило сопоставления на понятных примерах. Как найдут существующего покупателя? Что произойдёт, если совпадение неоднозначно? Можно ли объединить записи вручную и сохранится ли связь после этого? Для спорного случая лучше видимое исключение, чем автоматическое соединение разных клиентов.

Повторная передача одного заказа должна иметь заранее определённый результат. Обычно требуется обновление уже связанной записи, но конкретное правило зависит от процесса. Проверьте повтор без изменений, повтор с правкой и повтор после прерывания связи. Отсутствие дубля в одном успешном запуске ещё не доказывает устойчивость обмена.

Исторические данные выделите в отдельную задачу. Подключение новых заказов и перенос старой базы имеют разные риски и объём. Если нужно загрузить историю, укажите период, исключения, порядок сверки и ограничения на автоматические действия с документами. Не запускайте массовую обработку только для того, чтобы проверить соединение.

Что нужно получить от двух технических исполнителей

В документации Битрикс по интеграции настройки товарного обмена и обмена документами описаны отдельно. Для вашего проекта попросите специалистов совместно составить схему передачи: что отправляет каждая сторона, как подтверждается приём и где сохраняется ошибка. Названия технологий можно оставить приложением к этой схеме.

В оценке разделите настройку стандартных возможностей, адаптацию под доработки, подготовку данных и испытания. Если исполнитель называет только стоимость установки модуля, уточните, включены ли сопоставление существующих записей и проверка исключений. Именно на этих участках часто обнаруживается незапланированная работа.

Согласуйте отдельные тестовые учётные записи для исполнителей и порядок обмена диагностическими сведениями. Ошибка должна сопровождаться номером операции, временем и безопасным описанием, по которому обе стороны найдут нужный участок. Не размещайте в общей переписке выгрузки с паролями и полной клиентской базой.

Если каждая команда связывает сбой с работой другой стороны, координатор запрашивает один воспроизводимый пример и результаты проверки на границе передачи. Отправитель показывает, что именно передал; получатель — что получил и как обработал. Такой разбор помогает определить следующий шаг без взаимных предположений.

Определите порядок работы при сбое обмена

Временная недоступность одной системы не должна оставаться незаметной. Определите, где сохраняется неподтверждённая операция, сколько она ждёт и кто видит очередь. Для руководителя вопрос звучит просто: как мы узнаем о заказе, который ещё не появился в учёте?

Договоритесь о временной ручной процедуре. Кто проверяет новые обращения на сайте, как отмечает обработанные и как предотвращает дубли после восстановления? Такая процедура не обязана быть сложной, но её нужно испытать. Иначе после сбоя сотрудники заново вводят уже переданные заказы.

Повторы и восстановление выполняйте по понятным правилам. Не допускайте бесконечного молчаливого повторения неверных данных. Ошибка реквизитов требует исправления, а кратковременный разрыв связи может требовать повторной передачи; для бизнеса это разные причины и разные ответственные.

Как запустить обмен с контролируемой проверкой

Сначала испытайте процесс на копиях с подготовленными данными. Тестовая среда не должна отправлять настоящие уведомления покупателям, создавать реальные платежи или команды отгрузки. Подготовьте резервные копии и понятный способ возврата до первого изменения рабочих данных.

Приёмку разбейте на конкретные сценарии: новый заказ, известный клиент, новый клиент, изменение, отмена и повтор. Ответственный со стороны бизнеса подтверждает итог в обеих системах. Технический журнал прикладывают как свидетельство операции, но решение о правильности принимают по сохранённым данным и поведению процесса.

После переноса выделите период наблюдения. Сверяйте реальные операции и время прохождения, сохраняя идентификаторы для разбора. Если обнаружено расхождение, ограничьте проблемный участок по согласованному плану, вместо того чтобы продолжать неконтролируемую обработку всего потока.

Подробная проверка цен и остатков разобрана в статье о товарном обмене, а передача документов — в материале об обмене заказами. Используйте их как отдельные наборы приёмки, сохраняя общие решения в одном проектном документе.

Какие материалы оставить компании после завершения

Получите паспорт подключения, список источников данных, правила сопоставления, контрольные сценарии и контакты поддержки. Укажите владельца настроек и порядок выдачи доступа новому подрядчику. Работоспособность не должна зависеть от памяти одного человека.

Запишите, какие изменения требуют повторного теста: обновление 1С, смена модуля, новая организация, другой склад, новая схема цен или оформление заказа. Даже если соединение осталось прежним, смысл передаваемых данных мог измениться.

Для оценки интеграции в ШТАБ ИТ достаточно начать с паспорта систем и одного законченного процесса. Затем согласуйте источники, исключения и признаки приёмки. Это позволит сравнивать предложения исполнителей по одинаковому результату и передать команде действительно работающий обмен.