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

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

Событие формы

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

Эта тема отличается от агента для задач в 1С и общей автоматизации продаж. Здесь рассматривается один входной переход: веб-форма → внутренний сервис → карточка 1С. Цены, счета и дальнейшие этапы продаж оставлены существующим процессам. Такое ограничение позволяет проверить передачу заявки отдельно от качества работы менеджера.

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

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

Сопоставление полей

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

В платформе 1С:Предприятие описаны механизмы обмена с внешними системами, включая HTTP-сервисы и REST-интерфейс прикладного решения. Конкретный способ зависит от используемой конфигурации, версии и политики доступа. Разработчик 1С выбирает точку приёма и обеспечивает валидацию на серверной стороне; универсального поля «заявка с сайта» для всех конфигураций предполагать нельзя.

1. Зафиксируйте реальные поля формы и их смысл для менеджера.
2. Сопоставьте их с конкретной конфигурацией 1С и обязательными реквизитами.
3. Опишите нормализацию телефона, почты и свободного комментария.
4. Проверьте запись на пустых и ошибочных значениях.
5. Сохраните исходное событие и итоговую карточку для сверки.

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

Дубли и повторы

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

Поиск похожих заявок по телефону и имени решает другую задачу. Один клиент вправе оставить несколько разных запросов, а общий телефон компании встречается у разных людей. Такие совпадения показывают менеджеру как возможный дубль. Автоматическая обработка повторов опирается на постоянный ключ одного события, а решение об объединении разных заявок принимает сотрудник. ИИ может подсветить сходство комментариев, сохраняя исходные заявки в журнале.

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

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

Статус и журнал

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

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

1. Отправьте корректную форму и проверьте карточку 1С.
2. Искусственно повторите событие с тем же ключом.
3. Смоделируйте отказ сервиса после фактической записи.
4. Проверьте валидацию ошибочного поля и очередь ручного разбора.
5. Сверьте число событий сайта с подтверждёнными карточками и открытыми ошибками.

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

Пилот интеграции

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

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

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

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

Частые вопросы