Если заказ появился в 1С после ручного запуска обмена, закрывать задачу рано. Бухгалтерия получила документ, но причина задержки осталась неизвестной. Пройдет ли следующий заказ автоматически, пока никто не проверил.
У сотрудника есть понятная причина остановиться здесь: ему нужен заказ, чтобы выставить счет или оформить отгрузку. У специалиста по обмену задача еще не закончена. Нужно выяснить, почему штатная передача не сработала и что изменилось при ручном запуске. Иначе кнопка синхронизации постепенно станет частью ежедневной работы.
Это особенно важно, когда CRM и 1С сопровождают разные специалисты. Отсутствующий заказ видят оба, но каждый проверяет свою систему. Связать их выводы можно через конкретную сделку, время отправки и ответ на запрос. Иначе фразы «у нас все работает» вполне могут описывать разные части одного обмена.
Начните с заказа, который не дошел
Для первого разбора нужен один документ, по которому можно восстановить действия сотрудника. Какая сделка должна была его создать, в какой момент и что ожидали увидеть в 1С. С номером и временем уже можно искать соответствующие записи в журналах.
Сначала проверьте само ожидание. Переход сделки на стадию запускает создание заказа только в том случае, если так настроена интеграция. Наличие Коннектора этого не гарантирует. В нем есть отдельные механизмы синхронизации, автоматизации и работы с документами, а состав доступных объектов зависит от конфигурации 1С. Это описано в справке о Коннекторе к 1С.
Поэтому перед разбором полезно открыть настройку или ТЗ и найти правило для нужного документа. Если правила нет, сначала придется согласовать, что должно происходить.
Дальше проверьте, действительно ли заказ отсутствует. Поиск по названию клиента может не показать нужную запись. Нужны связь со сделкой и идентификатор, а при проверке списка следует учесть организацию, фильтры и права сотрудника. Создать второй заказ быстрее, чем найти первый, но затем придется разбираться уже с двумя документами.
Для задачи сохраните ссылку на сделку, время события и ее состояние до повторного запуска. Если заказ все-таки найден, добавьте его ссылку. После этого можно сравнивать, что происходило в двух системах с одной и той же записью.
Журнал показывает, что произошло при конкретной попытке
Дальше названия разделов относятся к Коннектору к 1С от Битрикс24. Если обмен сделан другим приложением или доработкой, расположение журналов и состав записей нужно уточнить у разработчика.
В Коннекторе историю запросов можно открыть в 1С через раздел Битрикс24 > Сервис > Журнал взаимодействий. Там есть отправленные данные, ответы и служебные операции. Подробность и срок хранения зависят от настроек, поэтому сначала выберите период и подключение. Инструкция по журналу взаимодействий
У пустого списка есть несколько объяснений. Запрос мог не отправиться, запись могла попасть под другой фильтр или уже удалиться по сроку хранения. Отсутствие строки само по себе еще не позволяет сказать, что 1С ничего не отправляла.
Если нужные записи сохраняются, но для проблемного объекта их нет, проверка возвращается к запуску: попал ли документ в отбор, зарегистрировалось ли изменение, выполнилось ли задание. Здесь помогает соседний документ, который прошел успешно. Сравнивать имеет смысл конкретные различия: организацию, вид документа, состояние, значения реквизитов. Это дает проверяемую версию причины.
Если запрос найден, нужен его полный ответ. В Коннекторе есть и отдельный журнал ошибок синхронизации; записи в нем сохраняются при включенной настройке хранения ошибок. Как посмотреть ошибки синхронизации
Не ограничивайтесь строкой об успешном завершении обмена. Нужно понять, к какой операции она относится: чтению списка, созданию документа или обновлению нужного поля. Успешное выполнение одной операции не подтверждает, что весь заказ передан правильно.
Когда деталей не хватает, администратор может включить отладку и воспроизвести сбой. Для этого заранее выбирают пример и время проверки: подробный журнал увеличивает базу 1С, а бесконечно собирать все запросы ради одной ошибки незачем. Фрагмент для подрядчика нужно обезличить и очистить от ключей подключения и паролей.
Почему ручной запуск проходит, а автоматический нет
Рабочая ручная попытка дает полезную точку сравнения. Вы уже знаете, что этот объект удалось передать при таких настройках и в это время. Из этого еще не следует, что автоматический запуск использует те же условия и что соединение было доступно минутой раньше.
Если обмен идет по расписанию, проверьте выполнение задания, его время и результат. Если настроен режим реального времени, уточните механизм связи и событие запуска. Проверять публикацию HTTP-сервиса нужно в том случае, когда интеграция действительно использует его.
Для такого подключения в официальных ответах Битрикс24 разобраны ошибки учетных данных и прав, неправильная публикация сервиса, а также неполный адрес базы без протокола. Эти проверки относятся к подключению через HTTP-сервис; для другого механизма они могут быть неприменимы.
Со статусом 404 тоже полезно сначала прочитать адрес запроса. Он показывает, куда обращалась система. Уже затем администратор проверяет, верен ли путь и опубликован ли нужный сервис. Один код ошибки не объясняет, что изменилось в вашей установке.
После исправления следует повторить автоматический сценарий. Еще один успешный ручной запуск подтвердит только то, что уже работало.
Документ появился, но сумма или статус не совпадают
На этом этапе повторять весь обмен обычно нет оснований. Нужно найти конкретное значение и проследить, откуда оно пришло.
Например, если в 1С видна оплата, а стадия сделки осталась прежней, проверьте, какое поле интеграция должна обновлять. Передача сведений об оплате и смена стадии сделки могут быть разными действиями. Нельзя считать второе выполненным только потому, что первое предусмотрено настройками.
Сначала посмотрите, было ли нужное значение в отправленных данных. Затем проверьте, в какое поле его записали и к какому объекту относится ответ. Если значение сохранилось, но пользователь его не видит, отдельно разбираются права и отображение карточки.
Еще одна ситуация: поле обновилось, а после следующего обмена вернулось назад. Здесь нужно проверить, кто его меняет в обеих системах. Когда CRM и 1С отправляют разные значения одного поля, повторная синхронизация способна снова воспроизвести тот же результат.
У синхронизации смарт-процессов в Коннекторе порядок загрузки и выгрузки влияет на обработку одновременных изменений. Он описан в настройках синхронизации смарт-процессов. Для других объектов и модулей правила проверяются отдельно.
В ТЗ для такого поля должно быть понятно, где его разрешено менять и какое значение принимается при расхождении. Тогда специалист сможет проверить настройку по этому правилу. Без него один отдел будет считать правильным значение из CRM, другой из 1С, а обмен продолжит выполнять то, что в нем настроили.
С дублями сначала проверяют связь между записями
Две одинаковые компании в Битрикс24 выглядят как задача на очистку базы. Но если копия появляется после обмена, начинать следует с проверки того, как 1С находит существующую компанию.
Коннектор хранит идентификаторы объектов Битрикс24 на стороне 1С. Они нужны, чтобы связать записи двух систем. В справке отдельно отмечено, что эти связи учитывают адрес портала. Поэтому после смены домена нужно проверить и адрес в подключении, и адрес у сохраненных идентификаторов. Как устроены идентификаторы Битрикс24
Если у объекта потерялась связь, новая отправка может создать еще одну запись. Удаление копий в CRM не восстанавливает соответствие автоматически. Перед объединением следует выяснить, на какую карточку ссылается 1С и что станет с этой ссылкой после операции.
Для уже заполненных систем в Коннекторе предусмотрен помощник ручного слияния данных. Он помогает сопоставить существующие записи. Проверку самих карточек, их полей и истории разбирает отдельная статья о дублях в Битрикс24.
По той же причине полный обмен не стоит использовать как универсальный способ восстановления. Если сопоставление ошибочно, он может затронуть больше записей с тем же дефектом. Для смарт-процессов документация рекомендует полную синхронизацию при начальном заполнении; способ повторной обработки при сбое выбирают с учетом причины и состояния данных.
Как понять, что обмен действительно починили
Исправление проверяется на исходном примере. Заказ должен появиться через предусмотренный автоматический запуск, связаться с нужной сделкой и получить согласованные значения полей. После этого имеет смысл проверить следующий документ и обновление существующего.
Отдельной проверки заслуживает повторная отправка. Документ уже создан, но команда запускает обмен еще раз. Если вместо обновления возникает копия, задача с дублями осталась открытой, даже когда журнал не показывает ошибок.
Для приемки можно оставить четыре результата:
- документ создался автоматически и связан с нужной записью;
- изменение дошло в согласованное поле;
- повторная передача не создала второй документ;
- после ошибки ответственный нашел проблемную запись и смог повторить обработку.
Последний сценарий с ошибкой проверяют на тестовых данных в согласованной среде. По нему должно быть понятно, где сотрудник увидит сбой и кто его разберет. Иначе о следующем пропущенном заказе снова узнают от бухгалтерии.
Подрядчику для этого нужен компактный материал: версии 1С и модуля, редакция Битрикс24, способ запуска, ссылки на объекты, время события и соответствующий фрагмент журнала. Дополните его изменениями перед сбоем, если они известны. Это позволит проверить одну и ту же попытку с обеих сторон.
Если выяснится, что правила создания документов и изменения полей нигде не зафиксированы, их можно собрать в рамках предпроекта интеграции CRM с 1С. Для производственного сценария отдельно рассматривается, какие сведения о заказах, счетах и оплатах нужны отделу продаж. По этим правилам затем и принимается обмен: сотрудник выполняет привычное действие, а нужный документ появляется без ручного вмешательства в синхронизацию.
