После доработки интеграции ИИ-агентом проверьте, что платёж из 1С попадает к нужному заказу в CRM, а повторный обмен не создаёт дубль. Затем испытайте частичную оплату, исправление документа и сбой связи. Начните на тестовой копии с одного покупателя: так бухгалтер и менеджер смогут сравнить записи без риска для рабочих документов. Ниже — порядок проверки, признаки ошибки и условия, по которым можно принять доработку.
Что согласовать до первого теста?
Сначала запишите, какая система отвечает за каждое поле. Например, бухгалтер подтверждает поступление в 1С, а CRM показывает менеджеру сумму оплаты и остаток по заказу. Если менеджер поменяет сумму в карточке сделки, это не должно исправлять бухгалтерский документ. Иначе при следующем обмене системы снова разойдутся.
Для каждой операции укажите источник, место назначения и правило сопоставления. УНП помогает найти организацию в Беларуси, но у одного покупателя бывает несколько заказов. Поэтому одной карточки контрагента мало: платёж нужно связать с договором, счётом или другим основанием, которое использует компания.
- Покупатель: как CRM и 1С находят одну и ту же организацию.
- Заказ: по какому полю платёж попадает в нужную сделку.
- Оплата: кто подтверждает её в 1С и что после этого видит менеджер.
- Исправление: как CRM узнаёт, что бухгалтер изменил или отменил документ.
- Контроль: где видно время последнего успешного обмена и кто получает сообщение об ошибке.
Сохраните эти правила рядом с задачей для ИИ-агента и разработчика. Агент может написать код по описанию, но он не знает, какой договор бухгалтер считает основанием платежа, пока это не сказано прямо. Вопрос о том, какая система владеет данными заказа, также выделен в материале «CRM интеграция с 1С: кто владеет данными о заказах».
Какие операции проверить на тестовой копии?
Попросите специалиста подготовить копию базы или тестовый контур и согласовать способ возврата к прежней версии интеграции. ИИ-агенту для доработки достаточно необходимых ему файлов и примеров структуры данных. Рабочую базу и действующие учётные записи для пробного запуска ему передавать не нужно. До проверки зафиксируйте текущую версию кода и настройки обмена.
Выберите покупателя с понятной цепочкой: заказ, учётный документ и оплата. Бухгалтер сверяет записи в 1С, менеджер — ту же сделку в CRM. Для каждого прогона записывайте исходный документ, ожидаемый результат и то, что появилось в карточке. Цвет стадии сделки здесь не заменяет проверку суммы и основания платежа.
- Проведите полную оплату. Проверьте покупателя, заказ, сумму поступления и остаток долга в CRM.
- Проведите частичную оплату. Убедитесь, что CRM показывает поступившую сумму отдельно от остатка и не помечает заказ как полностью оплаченный.
- Запустите обмен повторно без новых операций. У той же оплаты не должна появиться вторая запись.
- Исправьте или отмените тестовый документ в 1С. Проверьте, что CRM показывает актуальный результат и позволяет понять причину изменения.
- Прервите обмен в тестовом контуре, затем восстановите его. Проверьте сообщение об ошибке и передачу операции, которая ждала отправки.
Отдельно испытайте платёж, для которого нельзя уверенно определить заказ. Такая операция должна попасть на ручную проверку, а не закрыть первую похожую сделку. Если компания готовит акты для покупателей, порядок внутренней проверки расчётов и подготовки документа подробнее разобран в статье на belinfoclub.by.
Как понять, почему записи не совпали?
Начните с самого раннего места, где ожидаемая операция пропала. Бухгалтер проверяет, записан ли документ в 1С и верно ли указано основание. Затем специалист смотрит, попал ли документ в очередь обмена, была ли попытка отправки и какой ответ получила интеграция. Менеджер проверяет конечную запись в CRM. Такой маршрут быстрее приводит к причине, чем ручное исправление суммы в карточке.
В отдельных сценариях обмена зарегистрированные изменения можно проверить обработкой «Регистрация изменений для обмена данными» (справка «Синхронизация 1С CRM и iCRM – ответы на вопросы пользователей»). Но наличие этой обработки и её расположение зависят от конкретного решения. Попросите специалиста показать аналогичную точку проверки именно в вашей связке 1С и CRM.
После правки кода сравните настройки обмена с версией до доработки. Если пропали только новые операции, проверьте регистрацию изменений и журнал ошибок. Если записи приходят, но относятся к чужому заказу, смотрите правило сопоставления. Если при повторном запуске появляются копии оплат, исправлять нужно способ распознавания уже переданной операции. Обмен также способен перестать работать после обновления или доработки 1С, поэтому проверку повторяют после таких изменений (материал «Типовые ошибки интеграции CRM и 1С: почему обмен данными не работает и как избежать проблем»).
Для разбора ошибки сохраните небольшой пример: документ в 1С, соответствующую сделку в CRM, ожидаемый результат и запись журнала обмена. Если ИИ-агент менял код, приложите изменённые файлы. Тогда разработчик сможет воспроизвести сбой, а бухгалтеру не придётся объяснять техническую часть на словах.
Какие типичные ошибки мешают принять доработку?
- Проверили только успешную полную оплату. Добавьте частичную оплату, отмену документа и повторный запуск обмена.
- Сопоставили платёж только по названию покупателя. Проверьте организацию и основание расчётов; спорную операцию оставьте для ручного разбора.
- Оценили результат по статусу сделки. Сравните сумму, остаток долга и связь с конкретным заказом.
- Запустили код ИИ-агента сразу в рабочей базе. Сначала испытайте его в тестовом контуре и сохраните возможность вернуть прежнюю версию.
- Не назначили получателя ошибок. Укажите, кто смотрит журнал обмена и кому передаёт пример сбоя.
Доработку можно принять, когда бухгалтер и менеджер получили ожидаемый результат по каждому тесту, а специалист показал журнал обмена и порядок восстановления после сбоя. Зафиксируйте проверенные сценарии: они пригодятся при следующем обновлении 1С или CRM. Сейчас откройте одну оплаченную сделку и за две минуты проверьте три поля: сумму поступления, остаток долга и время последнего успешного обмена.
